Little Success Story - Tomcat Session Serialization using MongoDB

[Stephan]

Hi,

we were using mongo to sync our sessions. We used to store data int mongo using Java internal byte serialization and it worked fine. But slowly...

Now we switched to Morphium (http://sboesebeck.github.io/morphium/) for synchronization and the speed gain is really cool:

So, to make things short:

- use mongo to synchronize Sessions in tomcat cluster works great

- do not use java byte serialization

- JSon serialization has lots of advantages, like speed and you actually can browse the session in mongo directly

Cheers,

Stephan

[Felipe Albrecht]

Cool,

may you explain how do you use mongo to synchronize the session?

Thanks,
Felipe Albrecht 

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/a7ea88ff-0139-4254-a72e-c5e4b00af99a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stephan]

Well, it's a bit "complex"...

1st we used a simple mongo-collection only containing documents with two fields: SessionID and binary data which is the serialized session.

This had several disadvantages and it's slow.

As this was not part of our build and it caused trouble with doublicated dependencies and stuff, we decided to rewrite this code.

We use morphium in our productional environment and so we decided to use it to serialize the session as well.

This are some things we had to take care of:

• Morphium relies on certain annotations, so we had to add @Embedded to all objects that were to be serialized using morphium
• The Session-Container needs to be part of the WebApplication, as it relies on user data.
• Hence we had a problem with class path and class loading in the TomcatManager (which obviously runs in a different scope than the webapp). The MorphiumSessionManager was built using reflection and strictly using the classloader of the WebApplicationContext.

The last item did take the longest to implement and to come up with. Acutally, storing into mongo worked fine, but restoring caused problems, as the Object would be instanciated in a differen Class Loader context. Using reflection we could define which classloader to use better.

Nevertheless, the session serialization is now about 10 times as fast as before. Thanks to Mongo!

[Stephan]

And for the mongodb-part of the synchronization:;

We just store all session data into one "special" collection, called "session".

On every node the session is being read from mongo, no caching allowed.

This way you don't need sticky sessions in a clustered environment of WebWorkers (like Tomcat)

We switched of all WriteConcern settings that might slow down the session writing, but also set the READ_PREFERENCE to PRIMARY in order to avoid "misses".

Am Montag, 12. Mai 2014 18:35:09 UTC+2 schrieb Felipe Albrecht:

[s.molinari]

Thanks for the clarification. I was interested in your answer too.

I am admittedly new to Mongo and even programming, thus I am curious why session data would need to be serialized. Can you expand just a little on that please?

Also, are you using TTL indexes to drop old session data within Mongo by chance? If yes, how well is that working for you? If not, how do you control session TTL?

http://docs.mongodb.org/manual/tutorial/expire-data/

Scott

[Stephan]

hi...

well serialization is just another term for translating your session data into JSon to store in Mongo. Mongo is not able to store, let's say a UserPricipal Object or something. So you need to serialize it. We use morphium to serialize POJOs (which is what we put into the session) and store it to mongo.

Yes, wie use TTL indices and it workes fine for us.

We set the expire date on every session from Application. the TTL Index is 0. We did that to be able to have different Session lengths, if necessary

works fine.

Before that, we had a manual process for erasing outdated session. Worked fine also, but I prefer not to bother with this ;-)

cheers,

Stephan