tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amit Chandel <>
Subject Re: serializing session in DB
Date Mon, 02 Mar 2009 21:21:12 GMT
Hi Chris,

Thanks for bringing up these concerns.

I did a more detailed analysis of our application. Though it keeps 5GB
of session data in RAM which are actually disk backed, the active
session data will only account for a maximum of 200MB per second. So I
am only required to persist this much data in DB every second.

Going with the in-memory session replication will require 10GB of RAM
on both the tomcat instances. When the session data gets replicated to
another node, it gets written on disk of the other node too. Its a
Wicket application, and I can't just get away with replicating the
disk based session data :-(

If I go with persisting sessions in DB, my RAM requirement drops to
only 5GB on the cost of more network traffic and 200MB of DB writes
per second. We plan to use an NDB cluster for that. But only issue is
that Tomcat doesn't persist sessions to DB synchronously as is the
case with in-memory replication where session data is first replicated
and then the request gets served. So if master fails, and the session
data has not been persisted, subsequent requests going to the other
tomcat node will see old session data from DB, and might frustrate the
*user*.  I would like to know how synchronous persistance of session
data with Tomcat is done in practice.


On Mon, Mar 2, 2009 at 12:23 PM, Christopher Schultz
<> wrote:
> Hash: SHA1
> Amit,
> On 2/28/2009 9:02 PM, Amit Chandel wrote:
>> I am trying to deploy a tomcat cluster. I was able to set up a test
>> tomcat cluster using in-memory replication with version 6.0.10, but my
>> session data is too much (almost 5 GB per tomcat instance, and using 2
>> nodes in cluster both instances will require 10GB of RAM to hold
>> session data).
> Wow, does this thing scale? 5 GB of session data is a /lot/. Have you
> considered using either db-backed sessions (that is, writing everything
> to the database instead of keeping it in memory) or having your
> application itself store things in the db instead of the session?
> - -chris
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla -
> YusAoJ1WNgnn7nnAul84qJ8E7MHHPlJB
> =G8Kk
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message