I think that I pretty much understand the answer now.  To clarify the
problem: when
I said that I have multiple "app servers" running, I meant http server
products by different vendors.

For example, I might have Gemstone and Weblogic servers being hit by a
unique web client.  Someone
browsing my site might be served pages from both servers.  So, if the
homepage is Gemstone and I get a new
servlet session with request.getSession(true) but the second page is
WebLogic and I also get a new servlet
session with request.getSession(true) now one physical client has 2
separate http sessions because I am on
2 different http server vendors products.   Now I would like to unify my
session by using a stateful session bean.
I create stateful session bean in Gemstone, put the handle in servlet
session.  Now if I could just easily pass that
handle thru http I could post it to a WebLogic page and put it into the
other session as well.  I guess this can prob
be accomplished thru byte to string conversion and http post or thru
persistence to db and http post of primary key value.
I just wanted to see if anyone else had already solved this problem.

=====
> -----Original Message-----
> When user logs in to web site, create new stateful session bean which
> holds "background color" ect.  Store handle to stateful bean in
> Session.  To avoid going back to db, when need to find out "background

> color" on later page, simply get the bean and ask.  If user changes
> background color, modify db and stateful bean.  All is well in the
> world.
>
To be clear, you have personalization information, which you want
cached,
and saved to a database. True?

> Now the problem.  I have 2 app servers.
>
Do you mean 2 physical machines, 2 app server instances running, what?

In some "app servers", multiple machines and JVM's have different
implications.

> So, I have 2 sessions that I
> need to reference this same stateful bean.
>
Why? Is this because you are load balancing across web servers (and
therefor
Servlet/JSPs)?

> How can I get the handle to
> be passed from app server 1 to app server 2?
>
If you have an app server that provides for shared http session state
across
servers, then you don't have to do squat. Otherwise you'll have to pass
the
handle through a DB or some other sharing mechanism.

> Do I have to persist the
> serializable handle with app server 1 sessId to the db and recover it
> and store it to app server 2 by passing server 1 sessId in http post
and
> then using it to do lookup and recovery of handle from db?
>
That is one reasonable approach.

> Can I pass a
> serializable handle thru a post and put it to session 2 somehow?
>
Handle is serializable, so you could turn it into a byte stream and then
a
string, and store it in the http protocol somewhere.

> Has
> anyone else solved this problem?
>
<vendor>
GemStone/J lets you share http session state across Servlet/JVM
instances so
you can avoid this monkey business.
</vendor>
> --
> Tom
>
> Thomas Preston
> Vacation.com, Inc.
> Engineering Department
> 617.210.4855 x 124
>
>
==========================================================================

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

--
Tom

Thomas Preston
Vacation.com, Inc.
Engineering Department
617.210.4855 x 124

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

Reply via email to