#7 optimistic locking

[Per Nyfelt]

The following is from an e-mail on "Long-running
transactions in Ozone?", 17-Apr-2001 (edited):

Q: I am using ozone in a Servlet environment as the
backend to a dynamic website.
It would be quite useful to be able to start an
explicit transaction at the begining of a "wizard'
(multi-page form with Back, Next, Finish, and Cancel
buttons) and keep it alive in the user's session
between requests. Can anyone give me some pointers on
using explicit transactions in ozone? The example
shown in /samples look pretty straightforward. What
are some pitfalls to look out for?

A: I don't know about pitfalls in ozone itself. The
question is if it is a good idea to keep a transaction
open over several pages since AFAIK ozone has
pessimistic locking, i.e. an update method locks all
used objects until the transaction is finished. So, a
user can lock the whole system until he finished the
forms and all other users have to wait.

Q: Ugh, that I didn't know. Well, I'll just have to
do it myself (sort of). Do you know if the lock still
allows reads?

A: A write-lock prevents reading so, you may have
multiple readers (otherwise ozone wouldn't be a multi-
user database ;-)) but you may have only one writer at
the same time.

It's a pessimistic locking with Multiple Reader One
Writer (MROW) locks. objects are locked when the are
accessed. The lock level (READ, UPDATE,
WRITE) depends on the lock level that is specified for
the method that is called. So, if you collect all data
of the long transaction in the first part of the
transaction and call all update methods at once at the
end than you only have READ locks (which allow
multiple readers) most of the time.

Anyway, some sort of optimistic locking is needed to
handle such long transactions in a real clever manner.
I was thinking about this a bit. We just need a time
stamp in the client proxies and a way to set this
timestamp. The API would look like:

LongProcess lp = objectForName(...);

// get the time stamp from the target object and store
// it in the proxy

lp.mark();

lp.doPart1(...);

...

try {
lp.doPartN(...);
}
catch (OptimisticLockingExc e) {
// lp was updated by another party since our last
// mark()inform the user and update the GUI (if
// needed)
}
finally {
lp.unmark();
}

Should not be that difficult to implement. Any
volunteers?