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