You would have to make sure the beans methods are synchonized for this to work.
Dwight Rexin wrote:
> James,
>
> I'd suggest you question the "frame" you've stuck the question in on this
> one. Try this angle on for size.
>
> What happens if you step out of pure servlet land and instead use a JSP page
> backed by a plain old java bean? Configure the POJB to live for the life of
> the web session - which matches pretty well to the expected life of a
> stateful EJB session bean. Poof. A difficult technical problem vanishes in
> a cloud of JSP java mist.... Must make somebody at Sun smile.
>
> That's my personal suggestion - not a vendor recommendation...
>
> Best,
>
> Dwight
>
> -----Original Message-----
> From: James Cook [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 18, 2000 4:48 PM
> To: [EMAIL PROTECTED]
> Subject: Vendor Challenge
>
> I thought I would start a new thread, because I think Dan Benanev's
> original
> question has gotten buried.
>
> Description
> ============
> J2EE examples from SUN and Ed Roman's "Mastering Enterprise
> Javabeans"
> describe a technique whereby a servlet stores a handle to a stateful
> session
> bean in an HTTP session object. When an incoming request is received
> by the
> servlet, the handle to the bean is restored and communication with
> the
> stateful session bean recommences.
>
> Problem
> =======
> Servlet's are most often deployed in a manner that allows multiple
> web
> client requests to be handled by the same instance of a servlet. If
> the user
> has two browsers open and pointing to the same servlet, it is
> possible for
> two separate threads of execution in the servlet to attempt access
> to the
> same stateful session bean. This will generate an exception.
>
> Challenge
> =========
> Are the standard examples of accessing stateful session beans from
> servlets
> flawed? How does your product determine that a client request is
> actually
> coming from a distinct client? How would you recommend these
> situations be
> implemented?
>
> Discussion Point
> ================
> It seems to me that a servlet represents a web application and it is
> not
> *wrong* that the two browser windows (or two frames in a single
> window)
> share the same HTTP object, and thus, the same stateful session bean
> handle.
> I think what many examples fail to mention is that this EJB
> reference is a
> shared resource that must be synchronized. The "best practice" that
> I would
> choose to put forth would read:
>
> Access to a stateful session bean object from within any application
> that is
> multithreaded (i.e. servlets) must be synchronized to ensure only
> one thread
> is executing at a time.
>
> Dooohhh. Sounds a lot like the spec, no?
>
> thanks,
> jim
>
> ===========================================================================
> 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".
