1 Reply Latest reply on Mar 17, 2003 2:25 PM by Sacha Labourey

    Managing state of clustered environment

    Marek Neumann Novice

      1) we need to manage stateful sessions (with complex session information)
      2) in a clustered environment
      3) session must survive a node going down (-->replication is mandatory)
      4) SOAP-enabled, NO web clients, client does not have notion of HttpSessions (so forget that)
      5) Session State should be kept in-memory (for performance reasons)
      6) make Session data persistent when session lifetime is over
      7) requests on the session always modify session information (no read-only requests)

      Possible Solution (A):
      - use EntityBeans to track Session State

      Problems with (A):
      - for the described scenario EntityBeans cannot be clustered without violating RQMT 3), 5) and 7)
      - main problem: there is currently no state replication for EntityBeans across cluster nodes (why????)

      Possible Solution (B):
      - use Stateful SessionBeans to manage state
      - SFSBs are synchronized across nodes, so it looks like all RQMTS apply and this is the way to go, but....

      Problems with (B):
      - there is no "finder"-like way of getting the SFSB instance for a particular session, so the reference to the instance must be kept somewhere
      - in web environments one would store the reference in the HttpSession but RQMT 4) disallows that
      - but how can this be solved with, let's say a SOAP Client who does have notion of HttpSessions? Where can the reference be stored?

      To me it seems once more that the spec is incomplete or am I just blind?

      Is there any way to solve this dilemma? Any thoughts appreciated.

        • 1. Re: Managing state of clustered environment
          Sacha Labourey Master

          Hello Marek,

          Both suggestion solutions can be used:

          Entity bean: simply share the DB between both nodes and, if you want in-vm behaviour, take a look at the cache-invalidation framwork available in 3.2 (clustering doco)

          SFSB: the problem is that it won't be stored to disk once it times out, but it may be very simply implemented.

          Otherwise, you may simply want to implement your own logic in an MBean that makes use of the clustering framework (or any clustered bean type).