:07 PM
Hi!
I came across this a few times already and I think it's finally time to resolve the following underspecified behaviour.
Some servlet container support so called 'delta-replication'. That means they only transfer session attributes to another cluster node if they got changed in a request (instead of always transferring ALL the session content to the other node/nodes). This is a nice feature as it
sometimes helps to heavily reduce the network traffic.
The underspecified area is how to detect WHAT to transfer.
Tomcat e.g. only transfers attributes which got set via a Session#setAttribute() in the current request. Other containers have since mimicked this behaviour but still there are subtle differences.
The tricky point is how to tell the servlet container that some attributes needs to get transferred despite it's instance reference in the Sessions attribute map did not change at all.
E.g. consider a
List<PurchaseItem> shoppingCart = new ArrayList<>();
session.setAttribute("shoppingcart", shoppingCart);
Now even if you change the content of the shoppingCart in subsequent requests the reference itself does NOT change. To tell Tomcat that this attribute still needs to be transferred in the delta-replication you have to invoke session.setAttribute again in those requests where you changed it's content.
I've seen this working pretty well but there are quite a few things which can get wrong.
E.g. Tomcat detects that setAttribute replaces 'itself' and thus suppresses the attribute 'destroyal'. Other containers just send out all the events like HttpSessionBindingListener#valueUnbound, etc.
At the end I was not able to get delta-replication running portably across servers and had to switch the feature off in a few of them.
I'm not quite sure if delta-replication should get mentioned in the spec at all but maybe it's worth to at least unify the 'destroyal' of attributes in such a case.
There are a few more subtle differences and maybe other users also have some quirks mode/hack/workaround to share.
LieGrue,
strub