using db instead of sticky sessions

[asookazian]

Seam 2.0.1.GA
JBoss 4.2.1.GA

Our Seam apps obviously make heavy use of SFSB and conversation contexts. We are considering using db instead of sticky sessions in our clustered Jboss environment. What is the official JBoss recommendation on this?

Database backed sessions are the easiest to understand. Session data gets serialized and stored in a database. The advantage of database-backed sessions is it's simplicity. The disadvantage is that the database is often the performance bottleneck of the system. By adding load to an already-loaded system, you may harm performance. One way around that bottleneck is to use a small, quick database like MySQL for your session store and save the "Big Iron" database like Oracle for your core database needs.

http://bbs.51jishu.com/ref/sessions.xtp

we are possibly moving to JBoss5 AS in the future as well.

according to page 336 (clustering jboss services section) of JBoss in Action MEAP pdf, for EJB SFSB you must have sticky-session load balancing.

Does this mean that the db option above will not work? I've always read about sticky-sessions for SFSB's...

[brian.stansberry]

Not sure if you are talking about web sessions or SFSBs or both. The referenced doc is about web sessions.

Anyway, for SFSBs at least, JBoss has no option to use a DB to persist your bean after every request. Passivation to the file system is supported, but that doesn't write the session to disk after every update; only when the bean should be swapped to disk to conserve memory.

So, if you want to cluster SFSBs you need to replicate them, and that requires sticky sessions.

Same basically applies to web sessions, although there is a web session manager in Tomcat (and perhaps in JBoss Web) that can write to a db. Not sure if that's only for passivation as well. Last I looked at it a couple of years ago it wasn't really production ready. Could have changed though.

[asookazian]

An SFSB’s state can be saved in a persistent store in case a server instance fails. The state of an SFSB is saved to the persistent store at predefined points in its life cycle. This is called checkpointing. If SFSB checkpointing is enabled, checkpointing generally occurs after any transaction involving the SFSB is completed, even if the transaction rolls back.

http://docs.sun.com/app/docs/doc/819-3672/beaib?a=view

So JBoss 4.2 or 5 AS does not have this capability? I'm wondering if any other JavaEE servers support checkpointing? This is most likely the route my team-member was interesting in going...

[asookazian]

"asookazian" wrote:

An SFSB's state can be saved in a persistent store in case a server instance fails. The state of an SFSB is saved to the persistent store at predefined points in its life cycle. This is called checkpointing. If SFSB checkpointing is enabled, checkpointing generally occurs after any transaction involving the SFSB is completed, even if the transaction rolls back.

http://docs.sun.com/app/docs/doc/819-3672/beaib?a=view

So JBoss 4.2 or 5 AS does not have this capability? I'm wondering if any other JavaEE servers support checkpointing? This is most likely the route my team-member was interesting in going...