[EMAIL PROTECTED] wrote:
> > 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.
Here's another way of looking at this. Lets say for a moment that
we have two kinds of transaction:
(1) A business transaction.
(2) A database transaction.
Everyone seems to want to find ways of storing the uncommitted
work of the business transaction as state within a session bean until
the user says "go to it", and then have the session bean save changes
to the database in a single database transaction. Thereby business
transaction = database transaction.
Long ago, before EJB and distributed transactions, back in the days
of 2-tier and a single database, people solved this problem very simply
by observing that one business transaction can be equivalent
to multiple database transactions. You just need to apply a little
thought when designing your DB schema.
Let me explain with an example.
In this case, a business transaction is a set of payments, all requiring
a single receipt. For example, your city rates bill, plus your parking
ticket plus your dog license will all be payed with a single cheque,
(or ATM, or credit card) and a single receipt will be issued.
So we create a new receipt entity in the DB, and set its status
to "New". While the business transaction is in progress, we create
a new payment entity in the DB for each payment, and associate
the payments with the receipt (simple master-detail relationship).
Note: each time we create a new receipt or payment entity in the
DB we commit the DB transaction.
When we want to commit the business transaction, we simply
update the receipt entity and change its status to "Used", or
some such. One hit to the DB, one record to update. Wow
didn't that commit fast! I'll shop here agin, thanks!
A system of this kind is in place in my city. It works well, and
allows recovery and continuation of incomplete business transactions
even after serious disruptions to the DB server, client failure and
restart etc. Some of these transactions require many hundreds of
payments on a single receipt. If you were to batch up all these
changes as recoverable state in a session bean, when the time
comes to commit your huge database transaction, you will
possibly have serious problems with deadlocks and/or DB
server response time (seconds may be too long, let alone minutes).
Now, bringing this all back into the EJB world, I would suggest
that you consider a design where the business transaction is
equated to an instance of an entity bean. The final "done" or
"commit" method on the bean commits the business transaction.
Never mind that multiple DB transactions have been used.
Two downsides to this approach:
(1) You have to design your DB schema accordingly. Unfortunately
this falls in the too-hard basket for many customers, especially
the ones who are keen on session beans and entity beans with
container-managed persistence.
(2) You may end up with clutter in your DB, e.g. in the above
example, old receipts from days ago with a status still = "New".
You might want to clean these up or archive them occasionally.
However you can now do some interesting data mining on the
business transactions that were left incomplete, e.g. send
follow-up emails to your potential customers.
===========================================================================
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".
