JSP are simply servlets in disguise. The problem does not go away. I'm not even sure
what problem you are solving?
If two browsers access the same servlet on the same machine, the servlet gets the same
session cookie for both requests. A stateful session bean handle stored in this
session would point to the same stateful session bean instance, resulting in an
exception if accessed concurrently.
This is true whether using servlets or JSP...?
jim
On Tue, 18 Jan 2000 17:26:27 -0800, Dwight Rexin <[EMAIL PROTECTED]> 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".
>
It's almost
===========================================================================
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".
