One of the things that David Sims discovered was that his EJB server was
keying "identity" off of the thread. Thus, an existing Session bean, when
referenced by a second servlet hit in a new thread, was dropping the role
and principal that had been established by the first servlet hit. This
seems to preclude the solution described below.
< please correct me if I am misrepresenting this case, David >
So, I believe the approach that David took was to store the user's name
and role in the servlet session, and use this with each hit for the
InitialContext call. I do not know if he has any stateful SBs behind
this part or not.
I would like to know if any other EJB servers use this approach of tying
"identity" to the thread.
tim.
> Dave
>
> I think this document will explain why its better to use stateful session
> beans than servlets holding state. Servlets can be used simply as a conduit
> for bringing a client's invocation into the EJB container. All session state
> management takes place in stateful session beans.
>
> http://www.inprise.com/appserver/papers/11501_clustering.pdf
>
> kind regards,
>
> William Louth
===========================================================================
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".
