Re: [Modeling-users] Rollback?

[<sbi...@us...>]

Wolfgang Keller wrote:
[...]
>> Explicit database-locking would be called Pessimlistic Locking, where=20
>> modifying an object implies acquiring a lock on the corresponding data=
base=20
>> column(s) until changes are saved (or discarded).  This feature is on =
the=20
>> TODO list, but development has not started yet.
>=20
> Any realistic estimate when it will be available?
>=20
> In a transaction-intensive application, not having pessimistic locking =
will=20
> mean getting lots of transaction failures, I guess? And lots of handwor=
k to=20
> clean up afterwards...

You're right, if the application is very busy, you'll get a lot of failur=
es.
However, it's really application-specific: if most conflicts can be progr=
ammatically solved your application will softly behave under optimistic l=
ocking; if not, agreed, pessimistic locking is needed.

But, given that pessimistic locking locks any data that is going to be up=
dated, if your application is transaction-intensive updating the same dat=
a, you'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=
 not started implementing it.

> What I am in fact looking for is something that allows transactions at =
the=20
> object level to be as ACID as PostgreSQL transactions at the database l=
evel.
>=20
> 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 transac=
tions 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=
 something like a central server on top of the db & shared among differen=
t processes since the data still can be updated directly at the database =
level by any other process.

That must be the reason for wanting pessimistic locking. The pb. with pes=
simistic is that a transaction at the object level are likely to last muc=
h longer than standard SQL transactions (following the different steps of=
 updating data through numerous web pages for example), so in the meantim=
e, all other app. are denied starting any updates.


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

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

- optimistic locking: you'll get notifications when saving changes, givin=
g you the opportunity to examine the change and, e.g., automatically hand=
le them or provide feedback to the user.  As explained in a previous post=
, implementation has started: despite some limitations (w/ nested ECs and=
 the handling of deleted objects as well), it is in a sable state.

- pessimistic locking: locks rows before updating objects' attributes. No=
t started yet. You may want to bypass the lack of this feature by impl. y=
our own, simple, locking mechanism. For example, by overriding willChange=
() [ http://modeling.sourceforge.net/UserGuide/node75.html ]  and acquiri=
ng a global lock in the database  --agreed, this is simple, but locking s=
pecific rows (using info. of their GlobalID) needs a lot of care to avoid=
 deadlocks.


-- S=E9bastien.