Re: Rollback?

Wolfgang Keller wrote:
[...]
>> Explicit database-locking would be called Pessimlistic Locking, where =

>> modifying an object implies acquiring a lock on the corresponding databa=
se =

>> column(s) until changes are saved (or discarded).  This feature is on th=
e =

>> TODO list, but development has not started yet.
> =

> Any realistic estimate when it will be available?
> =

> In a transaction-intensive application, not having pessimistic locking wi=
ll =

> mean getting lots of transaction failures, I guess? And lots of handwork =
to =

> clean up afterwards...

You're right, if the application is very busy, you'll get a lot of failures.
However, it's really application-specific: if most conflicts can be program=
matically solved your application will softly behave under optimistic locki=
ng; if not, agreed, pessimistic locking is needed.

But, given that pessimistic locking locks any data that is going to be upda=
ted, if your application is transaction-intensive updating the same data, y=
ou'll get a lot of processes waiting at the same time.

To answer your question, no idea on a ETA for pessimistic locking --we've n=
ot started implementing it.

> What I am in fact looking for is something that allows transactions at th=
e =

> object level to be as ACID as PostgreSQL transactions at the database lev=
el.
> =

> Am I just dreaming?

No you're not: the framework bring the ACI properties at the object-level, =
and the Durability property on standard (non-nested) EditingContexts.

  http://modeling.sourceforge.net/UserGuide/nested-editing-context.html
  http://modeling.sourceforge.net/UserGuide/nested-ec-ACI.html

However, I understand what you mean here; you must be thinking of transacti=
ons being ACID when opened at the object level "down to the database".  But=
 we're not at the same level; it won't even help if the framework had somet=
hing like a central server on top of the db & shared among different proces=
ses since the data still can be updated directly at the database level by a=
ny other process.

That must be the reason for wanting pessimistic locking. The pb. with pessi=
mistic is that a transaction at the object level are likely to last much lo=
nger than standard SQL transactions (following the different steps of updat=
ing data through numerous web pages for example), so in the meantime, all o=
ther app. are denied starting any updates.


Well, I'll stop here, but if you really need to deal with concurrent update=
s of the same data I'll summarize the siuation:

- no locking (for now, the default): concurrent updates override previous c=
hanges, not even detecting that another process has changed the data (pleas=
e note the framework DO broadcast changes between threads)

- optimistic locking: you'll get notifications when saving changes, giving =
you the opportunity to examine the change and, e.g., automatically handle t=
hem or provide feedback to the user.  As explained in a previous post, impl=
ementation has started: despite some limitations (w/ nested ECs and the han=
dling of deleted objects as well), it is in a sable state.

- pessimistic locking: locks rows before updating objects' attributes. Not =
started yet. You may want to bypass the lack of this feature by impl. your =
own, simple, locking mechanism. For example, by overriding willChange() [ h=
ttp://modeling.sourceforge.net/UserGuide/node75.html ]  and acquiring a glo=
bal lock in the database  --agreed, this is simple, but locking specific ro=
ws (using info. of their GlobalID) needs a lot of care to avoid deadlocks.


-- S=E9bastien.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV