users@servlet-spec.java.net

[servlet-spec users] HttpSessionBindingListener#valueUnbound after setAttribute

From: Mark Struberg <struberg_at_yahoo.de>
Date: Sat, 24 Aug 2013 08:29:02 +0100 (BST)

Hi!

I've recently came across the following functionality working different on various containers.

User sets an attribute into the Session

setAttribute("storage", myStorage);

where myStorage is a Map<String, Object>;


After turning on 'delta-replication' (only replicating 'fresh' information to the other cluster nodes) this attribute will not be replicated if I only change the 'content' of my storage:

Map<String, Object> storage = session.getAttribute("storage");
storage.set("customer", newCustomer);


The changes on all servers I did test only only get replicated if I 'refresh' the session attribute:

session.setAttribute("storage", session.getAttribute("storage"));

This is also documented that way in e.g. the tomcat documentation but seems to work on all other containers as well.

Now for the DIFFERENCES:

Some containers (tomcat) detect whether the 'new' attribute value is == (identity equals) with the old value and in this case they do _not_ fire the valueUnbound for this attribute. But others do. Those others actually fire a valueUnbound _plus_ a valueBound for the same instance. This seems kind of weird to me. Especially since the order of these 2 events is not defined neither.


Sending both events seems more in sync with the spec wording, but the tomcat behaviour makes much more sense from a users pov.
Is there any chance to clarify this in the spec?

txs and LieGrue,
strub