Improve HttpSession distribution semantics

[glassfishrobot]

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?

[glassfishrobot]

@glassfishrobot Commented
Reported by gregwilkins

[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]

@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]

@glassfishrobot Commented
mode said:
Adding it to the bucket of FUTURE_RELEASE

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA SERVLET_SPEC-1

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/servlet-spec/issues/1
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[manorrock]

@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.