To deal with the bean per client issue in the stateless case you can map the
stateful session bean to the http session state (store a handle for the SB
in the http session state).
You still have the issue of how to establish the principal on the stack
before invocing on the bean... Is there a J2EE standard way to achieve this?
-Chris.
> -----Original Message-----
> From: James Cook [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, January 20, 2000 7:17 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Vendor Challenge
>
> 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".
===========================================================================
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".
