Having just finished rolling out a servlet-based web app, and am now looking
at developing the next version of using EJBs.
In an number of cases, we query information from the user over a sequence
of pages, and finally do all the database updates when the final "Submit"
button is pushed. A pretty standard paradigm, I guess; we call this kind
of multi-page operation a "dialogue". Our current app handles dialogues in
a pretty simple-minded way, passing around all the collected data in hidden
fields.
Having read about stateful session-beans in Mr Monson-Haefel's EJB book,
I'm hoping they could provide a better way of implementing dialogues. As I
understand it, the session bean can perform any number of operations within
a single transactional context, until finally it decides that it's time to
commit.
But, I'm wondering whether this is actually workable, and scalable. What
(if any) are the disadvantages of keeping database transactions open across
HTTP requests? If the user walks away in mid-dialogue, at what point will
the EJB server time-out the session-bean, and roll-back the transaction?
I think part of my confusion is that I'm unsure how locking and exclusive
access works with EJBs. If I have a stateful session-bean that performs
update on a number of entity-beans, does this imply that these entities are
inaccessible to other transactions in the meantime?
If you can enlighten me, I shall be most ... enlightened.
--
Mike W
===========================================================================
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".
