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.
