Terracotta the makers of JVM clustering technologies, has announced the availability of Terracotta Sessions for Tomcat. The product will be distributed with a license that allows you to cluster session state in up to four Tomcat instances for free.

Terracotta Sessions is built on Terracotta’s JVM clustering technology. This technology works to cluster objects at the JVM level and is enabled entirely through configuration. To use Terracotta you just drop it in. It does does not require developers to write any code or implement an API.

Unlike other clustering solutions, Terracotta Sessions only transmits data that has changed. Applications clustered using this technology have a much improved scalability. Features of Terracotta Sessions include:

• Drop-in clustering, no need to code to any API
• Real time monitoring of session contents
• High-availability and failover
• Automatic management of object identity (no need to keep foreign keys as class attributes)
• Will cluster objects that are not serializable, a requirement for session replication in most Servlet container
• Terracotta Configurator to assist in the configuration of Terracotta Sessions

Terracotta Sessions is most beneficial for those that have:

• Large sessions
• Deep session graphs with small changes
• Sessions containing non-serializable objects
• Servlet code that doesn’t call HTTPSession.setAttribute when the session state changes

The free version of Terracotta Sessions is now available for download.

Does this use a server (perhaps a replicated one) to store the sessions on? Thanks Guglielmo Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering .. or the World's First Pure-Java Terminal Driver

Does this use a server (perhaps a replicated one) to store the sessions on?

The data is replicated to all the other JVMs participating in the cluster. This process is managed by a process that is running in the background. Kirk

Does this use a server (perhaps a replicated one) to store the sessions on?

The data is replicated to all the other JVMs participating in the cluster. This process is managed by a process that is running in the background.

Kirk

Small correction: Terracotta clusters your JVMs using a central hub to broker the conversations. While scaling this hub is a challenge, it allows TC to cluster much like a buddy system. In this case, the Terracotta Server is every JVM's buddy. Most importantly, the centralized view of all heap requirements allows TC to page in on the fly when sessions are being requested by the Tomcat container itself. This means memory is totally virtual and you can store more session data than would fit in 32 bit heaps. Of course there are other ways to do this--partioned peer-to-peer caching would be one example--but TC's works and is free. Last, it is pretty much always drop-in for session in that you don't need session attributes to implement serializable and you don't need to call setAttribute() when you change the attributes; only on the first introduction of that attribute into the session graph.

i normally try to avoid content-free postings but i must say that this virtual shared memory technology seems absolutely amazing! it seems almost to be too good to be true...but of course there must be limitations, right?!: - i look at it basically as Tangosol without the API - but then Tangosol can be a transactional resource - which i've always through indispensible in an enterprise setting. (but that's probably a different mindset then that of virtual shared memory.) - any good distribute cache has plenty of paramters to tune replication of object state - i suppose it does not replicate the state of *all* objects between JVMs (if just to limit communication overhead), so i guess that if i fail to have it replicate all required objects the behaviour of my distributed app will be very surprising indeed - what about replicating the state of objects that are inherently JVM-dependent, like Thread or objects usually bound to a Thread, like Transaction? that surely can't work. so what if i want to replicate the state of an EJB3 stateful session bean, which contains a reference to an EJB3 EntityManager? that EntityManager state can probably not be replicated, can it? More to learn, then, but very exciting indeed! cheers, gerald http://www.gerald-loeffler.net

- i suppose it does not replicate the state of *all* objects between JVMs (if just to limit communication overhead), so i guess that if i fail to have it replicate all required objects the behaviour of my distributed app will be very surprising indeed
- what about replicating the state of objects that are inherently JVM-dependent, like Thread or objects usually bound to a Thread, like Transaction? that surely can't work>

Yes, ofcourse - by definition certain types of objects that represent native OS/host resources (such as file-handles, sockets, Database-connection-pool etc.) or represent JVM-specific resources (Runtime etc.) are inherently non-clusterable. You declaratively specify which object needs to be clustered (referred to as the "root") and that object and other objects it references are what get clustered. Additionally, the configuration allows you to specify if a specific-object in the object-graph being clustered needs to be treated as a "transient" from the clustering perspective. You can download a dev-license for free at www.terracottatech.com - Cheers.

We are looking forward to implement Terracotta Sessions for Tomcat for production deployment. Can anyone please let me know if terracotta sessions is being used in production environment already?