servlet
servlet copied to clipboard
jakartaee
Improve HttpSession distribution semantics
Currently there are significant ambiguities in the servlet specification with regards to how sessions should be distributed:
-
should changes made to the attibute value objects after the setAttribute be reflected in the persisted/distributed state? Is setAttribute pass-by-reference or pass-by-value ?
-
when is a session attribute persisted/distributed? When setAttribute is called? when the current request completes? when all simultaneous requests complete? at regular intervals? on container shutdown?
-
the requirement that only a single instance of a session is active in a cluster is difficult to efficiently implement. Can concurrent instances be allowed?
-
are sessions persisted/serialized attribute by attribute or as a single session blob?
- Issue Imported From: https://github.com/javaee/servlet-spec/issues/1
- Original Issue Raised By:@glassfishrobot
- Original Issue Assigned To: @glassfishrobot
@glassfishrobot Commented markt_asf said: Some additional questions related to distributed sessions:
-
When a session is distributed across multiple container instances, how should listeners be notified of HTTP session events? Only those listeners on the 'active' instance where the change originated, all instances, something else?
-
In the above case, should the listener notification behaviour be configurable, if so how and at what level (container, context, session, listener, something else)?
@glassfishrobot Commented mode said: In general so far Java EE platform does not talk about distributed semantics / HA behavior of containers. These features are left up to the container vendors to implement and make available. If we were to put details around distributed servlet programming model it would have to go beyond just HttpSession. At this time I am inclined to wait and see what we plan to do for Java EE platform as a whole before attempting to define distributed session semantics.
@glassfishrobot Commented mode said: Adding it to the bucket of FUTURE_RELEASE
@glassfishrobot Commented This issue was imported from java.net JIRA SERVLET_SPEC-1
@gregw My suggestion here is to strengthen the non-distributed contract to make clear what is expected in that case and state that if distributed is used that each instance should honor the non-distributed contract when accessing / modifying / adding / removing attributes when called on said instance and state that what happens on the other instances is up to the vendor to clearly document.
