Mike Williams wrote:
just out of curiousity, why don't you use servlet session data for the same
purpose that you are using your hidden fiels for? Are you worried about the
memory consumption of too many concurrent user session? I think using
transactions over multiple HTTP requests is quite an overkill with lots of
potential problems (locking, resource-consumption). I found that for many
applications, when you really calculate how many concurrent users you can
handle, you come to the conclusion that you can afford the servlet sessions. My
guess is, if you cannot afford keeping the data in servlet sessions then you
definitely cannot afford keeping transactions open over HTTP requests.
regards,
robert
> 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".
--
(-) Robert Kr�ger
(-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
(-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
===========================================================================
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".
