Thanks David, Your comments were very helpful. Is it possible for you to tell me, according to your experience, which of the options you mentioned would be advisable for a retail industry environment?
Thanks for your time, Alexandre Gomes On 12/3/06, David E Jones <[EMAIL PROTECTED]> wrote:
Fabian is right that we never explicitly lock a row, ie select for update. That depends totally on the transaction isolation. For most applications we recommend using a ReadCommitted or ReadUncommitted isolation level because RepeatableRead and Serializable generally have too much overhead and can result in table locks and such that increase the chance of dead locks and limit scalability. If you have sensitive data you have two options: 1. create a special database/schema for them and use Serializable or RepeatableRead for those (safest) 2. use the optimistic locking feature in the Entity Engine Option #2 basically shows the user an error and won't let them change the record if the data they are dealing with was updated between their read of the data (ie what is shown on the screen) and their write of the data (what they send to the Entity Engine). To use this just set the enable-lock attribute on the entity element in the entity def XML file to true. For more info on it just search around for "enable-lock". -David On Dec 2, 2006, at 4:46 PM, Alexandre Gomes wrote: > 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. >> >>
