Option 1:

Buckling down and incurring the cost of simplifying all of your session data suitable for cookies is one option, but tricky and difficult to do for many applications storing objects in session.

Option 2:

You might consider some RESTful SOA to talk between your variable stack of frameworks, but the cost of doing that is two fold. First, you must consider the security constraints of how the services would be consumed and restrict that to internal consumption to prevent leaking sensitive data. Second, it would increase the chattiness between the apps which could negatively impact performance if not done just right.

Option 3:

Storing session data in a shared database? Eh, no. Locking and transactional problems of a database shared between many applications is a recipe for disaster.

Option 4:

Memcached! OK, hear me out on on this one. Here are some of the advantages of using Memcached:

a.) Distributed high availability server
b.) Zero cross communication between the various applications for session data
c.) Memcached can support serialized objects, XML, YAML, and basically whatever
d.) Legacy application session stores can continue working almost the same only with a new hook to save and retrieve shared session data
e.) Memcached server cluster can be setup behind your firewall reducing any possibility of leaking sensitive session data to the outside world
f.) Minimizing complexity of security implementation (ie if a service based approach were used for cross-app session communication through services == more overhead)
g,) Chances are if you are using Ruby, PHP, or Python you already have Memcached as part of your architecture and if you don’t then it is a double bonus because of the added benefits that are yet to be realized for the new power of caching at your fingertips.

So here are some disadvantages:

a.) The language(s) your are using don’t have any open source support for communication with Memcached yet and you aren’t ready to incur the cost of developing it yourself
b.) Your organization prevents the use of this technology for whatever crazy reason
c.) Some will contend that if the Memcached server crashes your session data will be lost (same deal when your application servers crash though)

There are probably more disadvantages, but I am here promoting the use of Memcached so it is a little biased. Here are some visualizations of this idea. I put together a flow and sequence diagram. The underlying concept is that the all of the applications would need to read and write to a common cookie representing the key to look up the session data from Memcached.

Memcached Session Store