Thanks once more Fabian, I think even if you checked the timestamp before the update you wouldn't be sure your update targeted your actual data or data altered by another transaction that interleaved between your timestamp checking and the update. That is why the quoted example does a row lock.
Thank you once again for your time and see you tomorrow (I'm going to sleep now!) Alex On 12/2/06, Fabian Gorsler <[EMAIL PROTECTED]> wrote:
On Sat, 2006-12-02 at 23:11 +0000, Alexandre Gomes wrote: > Do we have to customize the Form widget or write the SELECT FOR UPDATE > explicitly? Or does the framework already contemplates this cases? AFAIK the Entity Engine just utilizes the concurrency features of your used DBMS with your specified isolation level and does not do own checks on the transactional state of rows. Checks whether data in rows has been updated could be implemented quite easy: For each entity the Entity Engine defines two additional fields (lastUpdatedStamp and lastUpdatedTxStamp - there are even two more, but they're not necessary in this case) and you could check with a service, whether this two time stamps have changed since you've fetched data from this row before you delete the rows. I could imagine there is already a service for doing that, but I don't know. Perhaps someone else could correct me or add additional information to this topic. I'm not sure, whether I'm writing the truth at the moment, but I hope I could help you. ;) Best regards, Fabian.
