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".
