Session Question

[Anthony Smith]

If I access a webapp that stores info in a session... If I access another webapp located on a completely different server, can he access the info that the other webapp stored in the session?
Rigt now, I dont have the means to try it.
SO, if I store a user object in a session, can another app on another machione access that user object?
This is something that I want to do... Have applications share info betweem each other via the session.
And, I am open to better suggestions.

[John Wetherbie]

Depends on the architecture of the system but the simple answer is no. However, you can get this to work by doing something like having both machines use the same DB and storing the info in the DB. Your session can have the session ID in it and the app checks the DB to see if it has the info for that ID stored in it. I'm pretty sure WebSphere does something like this.
Hope this helps.

[Remesh Govind]

Hi,
Many servers support clustering . Make sure u use one of those.
write it out to a common location (eg File ) then let the other servers app read when requuired.
Possiblity two:
Write a ServerSocket app that can pass this info to a client app on the other server.
Cheers

Remesh govind
P.S. Check info on D.M.Z etc. with ur sysadmin
look us java.net package.

[Rob Misek]

Hi Anthony,
Another way to solve this problem would be to use Tangosol's Coherence product which enables you to share data between JVMs through a java.util.Map interface complete with locking.
Also if you are using Tomcat 4.x, WebSphere 4.x or any Servlet 2.3 compliant app servers you can use our HTTP-Session Replication Module out-of-the-box to "cluster" the HTTP Session information.

[Frank Carver]

To summarize some of these points:
Sharing session information between separate JVMs (be they on the same physical machine or on different machines) is essentially the same problem as sharing any data between separate JVMs.
Many application servers have some built-in solution for this. Common solutions include: persisting session data to a shared file system, database, JNDI repository or JavaSpace etc; broadcasting update messages to a pool of servers whenever session data changes; and "sticky sessions" where the requests comprising one session are always routed to the same server.
All these solutions require that you ensure all data placed in the session is serializable. This is actually a requirement in the servlet specification, but many application servers are lax about enforcing it.
If you want to build your own solution for this sort of thing, you should consider the sort of data you will be sharing, and how often it is updated. For mainly static data, a "broadcast-update" solution (using JMS, for example) may be a good choice. For mainly transactional data, perhaps a shared database would be a good choice.
However you do this, bear in mind that it adds a lot of overhead and complexity to your applications. If you start sharing session data, you need to make extra sure that you keep an eye on what data gets put in the session. Repeatedly transferring too many large objects about can offset or even defeat the benefits gained from adding extra servers.

[Cameron Purdy]

Frank: "Sharing session information between separate JVMs (be they on the same physical machine or on different machines) is essentially the same problem as sharing any data between separate JVMs."
That's true. What differs is what "qualities of service" you are interested in. For example, should updates be transactional? Should they at least be coordinated? Or can they occur asynchronously? Should the data be in sync among the servers? Or is it OK to approximate coherency?
Frank: "Common solutions include: persisting session data to a ... database"
This is the most common but unfortunately scales very poorly. For performance, it is better to keep the data close to the logic, and the logic is in the application tier, so that is where the data should be (if possible). For scalability, sending traffic from all app servers to the database provides an obvious bottleneck. Even with only one or two app servers, the load on the database can be staggering; the popular site "TheServerSide.com" just ran into this when they implemented a cluster for their site -- they ended up with so much load on the database that it died!
Frank: "All these solutions require that you ensure all data placed in the session is serializable. This is actually a requirement in the servlet specification, but many application servers are lax about enforcing it."
I would add one other issue that we've seen: If you do a "getAttribute" on the session and you change it, you must call "setAttribute" or the change may not be stored (JDBC) or replicated (clustering technology) because the app server doesn't know that the data changed. This is a common problem.
Frank: "However you do this, bear in mind that it adds a lot of overhead and complexity to your applications. If you start sharing session data, you need to make extra sure that you keep an eye on what data gets put in the session. Repeatedly transferring too many large objects about can offset or even defeat the benefits gained from adding extra servers."
That can be true for a replicated cache, but for a distributed (partitioned) cache, it will scale indefinitely. It also has to do with the granularity; some app servers persist the entire session every request, which is expensive, but some implementations (like Coherence) cluster-replicate just modified attributes and properties.

[Frank Carver]

That can be true for a replicated cache, but for a distributed (partitioned) cache, it will scale indefinitely. It also has to do with the granularity; some app servers persist the entire session every request, which is expensive, but some implementations (like Coherence) cluster-replicate just modified attributes and properties.
Sure, but what I was mainly trying to suggest is the sensible use of "request" and "application" (a.k.a "servlet") contexts in addition to the well-known "session" context.
I have seen too many applications where everything of interest is dumped in to the session "just in case" as soon as it is loaded from a database or received from a client. This habit works pretty well in a single-VM session (given enough memory, of course), and can actually give rough-and-ready performance gains. As soon as sessions are shared, by whatever means, it can lead to lots of wasted bandwidth and serialization overhead. And by then it's often hard to track down which session items are actually needed.

[Cameron Purdy]

Excellent points!