• New Feature
  • Status: Open
  • 2 Major
  • Resolution:
  • Sessions
  • prodmgmt
  • Reporter: teck
  • September 10, 2007
  • 2
  • Watchers: 2
  • March 19, 2010


There are multiple issues with the current session implementation when/if sessions are accessed via “unusual” means. Normally sessions are looked up via the HttpServletRequest.getSession(..) methods. If session instances are made accessible via another means (e.g. a static map, a shared DSO data structure, etc), a variety of problems happen.

The “normal” session lookup path does a few things that are subverted when sessions are made accessible:

1) No DSO lock started 2) transients in SessionData not initialized

The first item can lead to unlocked expceptions and/or assertion errors in invalidate(). The second leads to NPE

A valid use case for doing something like this is to prevent a user from starting more than one valid session in the cluster.


Tim Eck 2007-09-20

another use case scenario for non-request based session access http://forums.terracotta.org/forums/posts/list/478.page

Fiona OShea 2008-03-05

We have more or less promised this to the forum user for Quintara. http://forums.terracotta.org/forums/posts/list/840.page

Alex Miller 2008-11-05

Copied over from RMP-298:

“Need to add a user story about a case where a user might get an object graph from an HttpSession attribute, then need to lock on the same lock we’re using on getAttribute(). This seems rare but possible. In that case, they can just use the same sessionId named lock. “

Basically, might need to consider whether we need to expose the lockable item for public use.