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