Re: [GENERAL] Tracking row updates - race condition

2005-03-29 Thread Alex Adriaanse
Harald Fuchs wrote: In article <[EMAIL PROTECTED]>, Alex Adriaanse <[EMAIL PROTECTED]> writes: Thanks for the input everyone. I think Harald's approach will work well... I'm not so sure anymore :-( Consider something like that: UPDATE tbl SET col1 = 1 WHERE col2 = 1; UPDATE tbl SET col1 =

Re: [GENERAL] Tracking row updates - race condition

2005-03-29 Thread Harald Fuchs
In article <[EMAIL PROTECTED]>, Alex Adriaanse <[EMAIL PROTECTED]> writes: > Thanks for the input everyone. I think Harald's approach will work > well... I'm not so sure anymore :-( Consider something like that: UPDATE tbl SET col1 = 1 WHERE col2 = 1; UPDATE tbl SET col1 = 2 WHERE col2 = 1; w

Re: [GENERAL] Tracking row updates - race condition

2005-03-28 Thread Alex Adriaanse
Thanks for the input everyone. I think Harald's approach will work well, so I'm planning on doing what he suggested, with a few modifications. I think I can still use a sequence-backed INTEGER rather than TIMESTAMP, and have the trigger that sets the revision to NULL also NOTIFY the daemon th

Re: [GENERAL] Tracking row updates - race condition

2005-03-21 Thread Harald Fuchs
In article <[EMAIL PROTECTED]>, Alex Adriaanse <[EMAIL PROTECTED]> writes: > I think that would greatly decrease the chances of a race condition > occurring, but I don't think it'd solve it. What if 150 other > revisions occur between a row update and its corresponding commit? How about the foll

Re: [GENERAL] Tracking row updates - race condition

2005-03-21 Thread Alex Adriaanse
I think that would greatly decrease the chances of a race condition occurring, but I don't think it'd solve it. What if 150 other revisions occur between a row update and its corresponding commit? Alex Vincent Hikida wrote: To fetch all updates since the last synchronization, the client would

Re: [GENERAL] Tracking row updates - race condition

2005-03-20 Thread Vincent Hikida
To fetch all updates since the last synchronization, the client would calculated a value for $lastrevision by running this query on its local database: SELECT max(revision) AS lastrevision FROM codes; It would then fetch all updated rows by running this query against the server: SELECT * FROM c

[GENERAL] Tracking row updates - race condition

2005-03-20 Thread Alex Adriaanse
I'm working on an application where we have a central database server and a bunch of clients that are disconnected most of the time, need to maintain a local copy of the central database. The client databases are based on One$DB since it has to be lightweight. The client does not access the s