Just becuase you have a stateful session bean doesn't mean you have to keep
a long transaction open! Separate conversational state from transactional
updates/queries in your design.
Ian from IBM has some good posts on this concept in the archives.
-Chris.
> -----Original Message-----
> From: Mike Williams [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, October 21, 1999 6:27 PM
> To: [EMAIL PROTECTED]
> Subject: stateful session beans & long transactions
>
> 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".
===========================================================================
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".
