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