Dain Sundstrom wrote: > On Jul 14, 2006, at 1:47 AM, Greg Wilkins wrote: > >> This is my idea of how we could morph the currently proposed session APIs >> into a cluster API. >> >> I have created a spot for Cluster meta data - but I have not filled it >> out much. >> >> The key difference is that the state Map is now indexed by session ID >> and context ID. >> This allows the state for different contexts within the same session >> to be on different >> nodes (this is a real requirement) > > I think I missed some of the discussion. Why is this a requirement? I > know some deployments like to split applications into multiple tiers, > but why would the servlet or ejb containers need to know about that?
I can see many reasons for having a session be a map of maps rather than just a flat map: The actual thing we are modelling is a map of maps. We know that beneath a session ID there can be multiple non-intersecting state spaces for EJBs, webcontexts, POJOs, whatever. If we know this is the model why not model it in out data structure? If the underlying implementation is just a single flat space, then it is trivial to store a map of maps into a single map by adding name prefixes. But if the underlying implementation is capable of modelling a map of maps, then we avoid the inefficiencies of adding prefixes for every lookup, excessive iteration, coarse locking etc. Conversely, if our API is a flat space - all the state for all contexts must be collocated and a request to one context will lock the entire state. Note that with mashups and portlets, you can expect that multiple contexts for the same session could be accessed in parallel. Heterogeneous clusters are needed. As well as clusters that are partitioned by tier (which if often a bad idea), we need to support clusters partitioned by context (some web contexts to a subset of nodes and others to another subset). This includes some single sign-on solutions which are actually multiple clusters sharing a session ID space. If a session state space is a single flat space, then it will be very difficult (if not impossible) to support heterogeneous clusters as the entire state for a session ID will need to be co-located. It may also be that individual context will need different locking strategies and their individual context maps can be wrapped accordingly. For example, some contexts may release their state map when a request has completed, while others may release after every setAttribute call (because they may be part of a long held Ajax/Comet request!) So I see a map of maps gives us much better targeted semantics with little extra complexity. cheers
