[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Long-running transactions in Ozone?
On Tue, 10 Apr 2001, Gerd Mueller wrote:
> > > > 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?
> > >
> > > 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.
> > >
> >
> > 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?
>
> I'm not quite sure if a write-lock prevents reading but I think
> so. 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.
Correct. 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?
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com