The simplest answer is to let the servlet maintain this type of session
state, and use stateless session beans for the search.
Stateful session beans are very expensive in EJB and should be used only
when a cheaper solution cannot be found. Because you are already
maintaining state in the servlet, using stateful session beans doubles the
amount of overhead used.
Note: I know of no way to portably clone any session or entity bean. (You
cannot clone a reference, which the servlet has. And, cloning a bean within
the container will not associate that bean with a new session). To
succesfully clone, a container clone_bean method is needed.
> -----Original Message-----
> From: Michael Pikounis [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 10, 1999 3:17 AM
> To: [EMAIL PROTECTED]
> Subject: Stateful session beans
>
>
> Hello all!
>
> I was wondering if there is a standard way to deal with the
> following issue:
>
> I have a servlet that accesses a stateful session bean to
> perform a search
> in the database. The Servlet provides some search criteria
> and the bean
> executes the query, saves the results in its state and
> returns a list to the
> servlet.
>
> The servlet can now select one of the "things" returned to
> see more details.
> It passes the unique ID to the bean and the bean performs
> another query to
> find the details of the "thing" selected. It saves the details of the
> "thing" in its state and returns the details to the servlet.
>
> Everything works fine, and my bean provides some state that
> is persistent
> across HTTP requests. The servlet can maintain some
> information there (e.g..
> The results of the query, the ID of the "thing" selected etc).
>
> The problem arises when the user decides to select the
> "thing" but in a new
> browser window. The new window will load the "thing" in the
> bean's state but
> the old window now "inherits" a state that is invalid (since
> in the old
> window the user has not yet selected anything).
>
> I can think of a few ways to deal with this but I am not sure
> which is the
> best. The simplest is to make my bean stateless and maintain
> state in the
> servlet. Passing the results as hidden fields could be one way..
>
> Alternatively, I could have my bean clone itself when a
> method that modified
> existing state is executed. This way the servlet can create
> the bean, add to
> its state, but cannot modify the state. In the example above,
> the "new"
> window would add to the bean's state, but when the old window
> asked for a
> different "thing" to be selected, the bean would clone
> itself, and the new
> instance would be returned to the old window. Eventually,
> unused beans would
> be removed() by the application server.
>
> I hope this was clear :-) Any ideas?
>
> Michael
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>
> ==============================================================
> =============
> 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".
