> But what if the user is going through a series of steps where each step
> requires user interaction and the steps should not be committed till all the
> steps are done. On one hand there's the issue of user going for lunch and
> hanging locks and on the other hand there's the issue of the system having
> commited to the the database only half the steps and user decides to log
> out.
>
> A typical example would be a user looking up a custom order , getting it's
> custom spec , changing the custom product spec , changing the shipping
> address on the order and then logging out.
>
> I'm being faced with this issue ? would you put these steps as different
> operations on a session bean ? When would you start the transaction and when
> would you commit it ?
If you want these kinds of long-lived transactions, you can't rely on simple
ACID transactions, cuz your whole database will get bogged down. Rather, you
need to lock objects for an extended period so that other clients can't modify
them. This is really what a distributed lock manager is for. I have not heard
any plans for introducing a distributed locking service into the Java Platform
for the Enterprise.
However, CORBA does specify a distributed lock service. There are many
interesting combinations of locks that you can acquire with CORBA's locking
service. Eventually there might be a CORBA vendor that implements this, plus
implements the new CORBA components spec so you can have components. But for
now I think you're stuck with either:
A) Finding an EJB server vendor that provides distributed locking in a
proprietary way.
B) Writing your own ad-hoc distributed lock manager.
C) Finding another workaround.
-Ed
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
