James Cook wrote:
>
> Sorry, but I wasn't exactly clear here.
>
> I know how sessions work in HTTP. When I stated the original question regarding
>client identity, I was referring to the EJB vendors. How do EJB vendors identify one
>client request from another? I'm sure the answer will vary, and I think it is
>important in order for some developers to understand.
When you're using EJB from Servlets you lose the client identity. All
your clients go through one Servlet, as far as the EJB server is
concerned there is one client. Of course that client can hold multiple
instances of session beans, it can run them in multiple transactions, it
can even make calls under a different principal/role. But it's still one
client.
In the EJB world (and also RMI/IIOP) the only thing that identifies you
is the object you reference. If two clients use the same object, they
are considered the same client. If one client uses two objects (i.e.
references to bean instances) it is considered two clients. So if you're
mapping bean to user, you will tend to have one stateful session bean
instance per Servlet Session.
Does that answer your question?
arkin
>
> jim
>
> On Tue, 18 Jan 2000 17:18:50 -0800, Assaf Arkin <[EMAIL PROTECTED]> wrote:
>
> >Cookies or session id ebmedded in the URI.
> >
> >If you have two distinct browsers (say two instances of Netscape, or
> >Netscape and IE on the same machine) than the cookie or session id in
> >the URI can identify you uniquely, as opposed to an IP (which also
> >breaks when using proxies, firewalls, etc).
> >
> >If you are trying to deal with two separate windows to the same server,
> >then your problem is that of HTTP not of EJB and simple examples like
> >those found in books do not work well.
> >
> >One approach we've been using is to have a session within a session. Say
> >the user starts at page A and follows two links to pages B and C in
> >three separate windows. Each link gets its own identifier passed through
> >the URI which is used to identify the process handled by that browser
> >thread (for lack of a better term).
> >
> >arkin
> >
> >
> >James Cook wrote:
> >>
> >> 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".
> >
> >--
> >----------------------------------------------------------------------
> >Assaf Arkin www.exoffice.com
> >CTO, Exoffice Technologies, Inc. www.exolab.org
> >
> > ==========================================================================
> >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".
> >
>
> Sorry,
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
