[Torque] SELECT for UPDATE
Next message: T.E. Schmitz: "[Torque] SELECT for UPDATE"
Date: Fri, 23 Apr 2004 18:21:50 +0100
As far as I can see there is no means of doing a SELECT for UPDATE in
Torque, i.e. it is not possible to lock a record in a transaction.
I need a locking read for the following reason:
Every record is marked with a 'LastUpdated' timestamp in order to enable
checking whether it has been updated in the meantime in another session.
Prior to any UPDATE or DELETE the record is re-read and timestamps are
compared. If the SELECT doesn't return any results the record has been
deleted. If the timestamp has changed the record has been modified in
the meantime. For this to work, the record needs to be locked by the
SELECT operation; otherwise there is still a window between the SELECT
and the UPDATE during which another session could modify or delete it.
Also, this is the only way of knowing whether the UPDATE has been
successful because Torque's doUpdate doesn't return the number of
effected rows.
Has anybody found a work-around for this problem?
--
Regards,
Tarlika Elisabeth Schmitz
Next message: T.E. Schmitz: "[Torque] SELECT for UPDATE"
Relevant Pages
- [Torque] SELECT for UPDATE
... Torque, i.e. it is not possible to lock a record in a transaction. ... Every record is marked with a 'LastUpdated' timestamp in order to enable ... checking whether it has been updated in the meantime in another session. ... (comp.lang.java.databases) - RE: Fragmentation Elimination Problem
... timestamp = datetimehour to hour ... look in the relative fragments. ... (comp.databases.informix) - Re: pessimistic locking
... >> Put a TIMESTAMP column on the table. ... >> If you really are convinced you want to lock the row, ... >> inserted into the data set by another user and are included in later ... This is the most restrictive of the four isolation levels. ... (microsoft.public.sqlserver.programming) - Re: Threading in Order?
... thread B then thread A's message goes in the log first do something like this (pseudo code): ... Just because thread A calls the LogAMsgmethod before thread B does, that doesn't mean that thread A will acquire the lock before thread B; it could happen to get pre-empted just before acquiring the lock, with thread B running immediately after and acquiring the lock before thread A. ... The best one can do is not generate a timestamp until the lock has actually been acquired, but then the timestamp winds up being not the time of the event being logged, but the time that the event _is_ logged. ... (microsoft.public.dotnet.languages.csharp) - Re: [PHP] Unique Object Instance ID..?
... private static $INSTANCES = 0; ... combining the three makes a unique id; but it's only unique to that session, no good for a real world application as there could be 50 sessions all running at the same time on the server; and odds are rather high that two instances of the object could have the same id. ... I'd thought a simple random integer would possibly be enough (combined with the timestamp), but there could still be collission. ... (php.general) |
|