3 Replies Latest reply on Jun 30, 2008 6:51 PM by Arbi Sookazian

    using db instead of sticky sessions

    Arbi Sookazian Master

      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...

        • 1. Re: using db instead of sticky sessions
          Brian Stansberry Master

          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.

          • 2. Re: using db instead of sticky sessions
            Arbi Sookazian Master

             

            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...

            • 3. Re: using db instead of sticky sessions
              Arbi Sookazian Master

               

              "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...