I have another thought on the same.
If I understand this correctly you do not need your user sessions in
both the web servers synchronized at all times all you need is session
state restoration on server 2 when user moves from server 1 to server 2
and visa versa.
If this is correct then you might want to consider the following:
1. Define a light weight serialization scheme for the objects you will
have in your sessions. (You might want to enforce this by having your
own Serialization tagging interface call it LightWtSerializable). The
idea is to have a thin serialized state of your objects (you might be
content with the std Java serialization too)
2. When user has to be redirected from Server 1 to Server 2. Server 1
creates a Light Wt Serializable copy of "Only" that Session state which
needs to be shared and adds it to the HTML page (may be as a hidden
filed value). In interest of security you might want to digitally
encrypt this Session state copy.
3. Server 2 gets the request and finds the Serailized ssn state, it
de-srializes it and creates a user session based on the same.
4. Same process repeats when user moves back from Server 2 to Server 1.
Important things to consider:
1. How being can the session state be?
2. How much of a problem it would be on second logon to server 1, if the
session state at Server 2 is not replicated on Server 1 because the user
just closed the browser while he was on server 2.
My 2 cents....
-Vikas
-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected)
Sent: Thursday, January 06, 2005 3:38 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Session Sharing
I think, sharing the session between two geographically distributed
servers
without any shared server infrastructure will not work: But what about
linking the two sessions using a common key? You can transport the key
via
the http-request and use this key to look up values from the session on
the
other server by jms or a webservice.
This, of course, is quite dangerous, as both servers have to be very
sure
about the users identity, as you're making a lookup on its behalf on the
other server. Using client certificates would be a way to make sure that
the
one who represents the key is properly authorized...
Hope this helps
stf
> -----Original Message-----
> From: An interest list for Sun Java Center J2EE Pattern
> Catalog [mailto:J2EEPATTERNS-INTEREST@(protected)
> Of Parag_Lonhari
> Sent: Donnerstag, 6. Januar 2005 09:39
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Re: Session Sharing
>
> Some time back I read of storing session context in Database.
> In that case geographically separated applications can use
> same session context.
>
> -----Original Message-----
> From: An interest list for Sun Java Center J2EE Pattern
> Catalog [mailto:J2EEPATTERNS-INTEREST@(protected)
> Of Sameer Nagaich
> Sent: Thursday, January 06, 2005 12:44 PM
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Session Sharing
>
> Hi,
>
> I have design requirement for which I need help.
>
> Requirement:
> I have a web application from where a user may choose to go
> to another web application hosted on another server in a
> geographically different location.
> After the user is done he would like to come back to the
> previous application and continue from where he had left.
>
> Problem:
> Is there a way to share the session created on the first
> application and use it in the second application. If yes how
> it can be achieved otherwise what is the work around to
> achieve a similar behavior.
>
> Regards
> Sameer
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com J2EE
> BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
> **************************************************************
> ************
> This email (including any attachments) is intended for the
> sole use of the intended recipient/s and may contain material
> that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any
> review or reliance by others or copying or distribution or
> forwarding of any or all of the contents in this message is
> STRICTLY PROHIBITED. If you are not the intended recipient,
> please contact the sender by email and delete all copies;
> your cooperation in this regard is appreciated.
> **************************************************************
> ************
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com J2EE
> BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
>
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
