I suppose you could start a client demarcated transaction in the servlet in
one http hit, and complete the transaction in another http hit. The
intermediate transaction handle could be stored in http session state...
But as Frank sais, this is a really bad idea!
-Chris.
> -----Original Message-----
> From: Frank Sauer [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, October 21, 1999 7:26 PM
> To: [EMAIL PROTECTED]
> Subject: Re: stateful session beans & long transactions
>
> The transactions won't span multiple http request though, unless
> you use client (servlet in this case) demarcated transactions or
> bean managed transactions, both of which I don't recommend.
> Your servlet calls a method on the EJB, this starts the transaction,
> and when the method returns the transaction commits. This is not
> related to the statefulness of the session bean.
>
> Hope this helps,
>
> Frank
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Williams
> 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".
===========================================================================
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".
