Are you generalizing, or are you talking about a specific EJB container?
>From what you are stating, I could never have a servlet talk to stateful
session beans, because every thread of execution in my servlet would be
talking to the same bean.
jim
----- Original Message -----
From: Assaf Arkin <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 19, 2000 3:35 PM
Subject: Re: Vendor Challenge
> 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".
>
>
===========================================================================
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".
