How best to make a transaction span multiple HTTP requests?

Question

Hi, all. What is the best way to implement a transaction that spans multiple
HTTP requests? Many J2EE applications must solve this problem, but I can't
any guidelines for an implementation.
Consider an application that implements a multi-step wizard. Each step
gathers data from the user; step one gets the user's name, and step two gets
his dog's name. When the user completes the wizard, the application saves
the user & dog in two entity beans. Conceptually, the application treats
this wizard like a single, long-running transaction. The transaction begins
when the user launches the wizard. Submitting the JSP for step one adds the
Boy bean to the transaction, and submitting step two adds the Dog bean.
Finishing the wizard commits the transaction. Exiting the wizard or timing
out causes the transaction to rollback.
Although the wizard looks like a transaction, the entire sequence of user
interactions can't be captured in a single JTA UserTransaction. A
UserTransaction must be associated with a single thread, but each wizard
step is handled asynchronously by its own execution thread. It's impossible
to funnel the conversation through one thread that can demarcate the
transaction. (This would be a pretty dumb solution for other reasons, but I
don't want to get lost in details.)
I think the standard way to solve this problem is to store conversation
state in a stateful session bean (or the http session) and create / update
both entity beans in a transactional EJB method after the wizard completes.
Unfortunately, this solution prevents me from leveraging a lot of great
transaction management features provided by the app server. For example, I
can't use optimistic concurrency to make sure that the dog object hasn't
changed in the database between the start and end of the wizard. Also, I'm
forced to keep track of changes to the dog object in the conversation state,
then replicate these changes to an entity bean at the end of the wizard.
Keeping track of state in a stateful bean is pretty straightforward, but it
seems like there must be an existing solution that leverages the appserver's
concurrency and state management features. Am I missing something? Is there
code, a pattern, or an article that describes the best way to implement a
multi-step process that looks transactional? I suppose WLI does what I want,
but that feels like killing a roach with a SCUD missle. Thanks for any
advice.
Dave

Answer 1

Dave Smith wrote:
Without a transaction, will the app server manage the version column
automatically, assuming of course that <concurrency-strategy> is
"Optimistic" and <verify-columns> is set to "Version"? Of course, I'll have
to expose the version as a cmp-field, which is fine with me.Yes
>
Do you know offhand, so that I don't have to get off my lazy ass and write a
test, whether the CMP service will create the version column when it
generates db tables? (I realize it's not good to let WLS generate the tables
in a production system.)No, I don't think it does.
>
I assume from your answer that I'm on my own for implementing stuff like and
transaction inheritance and tracking object modifications? Well, we'll give you a bit of help on the object modifications. The
usual pattern is when you're pushing the JavaBean back to the CMP you
call all the setXXX methods on the CMP bean. Our CMP container will
check if the value you are setting is the same as read from the db. If
so, it will not update that column.
-- Rob
If so, no big
deal. I was just hoping somebody would say, "Oh, you want the Jakarta
SuperBeans project" or something.
Thanks,
Dave
"Rob Woollen" <[email protected]> wrote in message
news:[email protected]...
I'd recommend that you include a separate version or timestamp column in
your db schema.
Then do something like this:
Client Server
1) First HTTP Request
2) Read current Dog and Boy Entity Beans
(if any) and copy their values into a JavaBean.
You want to include the version
column(s) in the JavaBean(s) along with the data values.
You probably also want to store the JavaBeans in
your HTTP Session.
3) Client proceeds through wizard interacting with JavaBeans
4) Finish with Wizard, copy JavaBean values (including
version columns) to CMP 2.0 Entity Beans.
The version column will give you the optimistic concurrency protection
that you desire without opening a JTA transaction to span user input.
-- Rob
Dave Smith wrote:
Hi, all. What is the best way to implement a transaction that spans
multiple
HTTP requests? Many J2EE applications must solve this problem, but Ican't
any guidelines for an implementation.
Consider an application that implements a multi-step wizard. Each step
gathers data from the user; step one gets the user's name, and step twogets
his dog's name. When the user completes the wizard, the applicationsaves
the user & dog in two entity beans. Conceptually, the application treats
this wizard like a single, long-running transaction. The transactionbegins
when the user launches the wizard. Submitting the JSP for step one addsthe
Boy bean to the transaction, and submitting step two adds the Dog bean.
Finishing the wizard commits the transaction. Exiting the wizard ortiming
out causes the transaction to rollback.
Although the wizard looks like a transaction, the entire sequence ofuser
interactions can't be captured in a single JTA UserTransaction. A
UserTransaction must be associated with a single thread, but each wizard
step is handled asynchronously by its own execution thread. It'simpossible
to funnel the conversation through one thread that can demarcate the
transaction. (This would be a pretty dumb solution for other reasons,but I
don't want to get lost in details.)
I think the standard way to solve this problem is to store conversation
state in a stateful session bean (or the http session) and create /update
both entity beans in a transactional EJB method after the wizardcompletes.
Unfortunately, this solution prevents me from leveraging a lot of great
transaction management features provided by the app server. For example,I
can't use optimistic concurrency to make sure that the dog object hasn't
changed in the database between the start and end of the wizard. Also,I'm
forced to keep track of changes to the dog object in the conversationstate,
then replicate these changes to an entity bean at the end of the wizard.
Keeping track of state in a stateful bean is pretty straightforward, butit
seems like there must be an existing solution that leverages theappserver's
concurrency and state management features. Am I missing something? Isthere
code, a pattern, or an article that describes the best way to implementa
multi-step process that looks transactional? I suppose WLI does what Iwant,
but that feels like killing a roach with a SCUD missle. Thanks for any
advice.
Dave