On 10/02/2015 08:03, Mark Struberg wrote:
>> I think we
>> should not try to come up with some "automatic" solution. Rather,
>> consider if we can create an API for developers to call that advises the
>> Servlet that a particular entry in the session should be replicated.
>
>
> Kind of a touch(String attributeName) or markDirty(String attributeName)?
>
> pro: more explicit
>
> con: needs a new API.
>
>
> The other option would be to define as standard what Tomcat does:
> Currently the spec defines that setting a 'new' object means that the 'old' object will get destroyed. The question now is what 'new' means? In Tomcat this got interpreted as only account as 'new' object if the newVal not equals the oldVal.
I think we should do a combination.
a) HttpSession.markAsDirty(String attributeName)
b) setAttribute() has an automatic side-effect of calling markAsDirty()
c) setAttribute() when the value is unchanged (i.e. the object being
passed is the same (read == ) as the object mapped to that attribute) is
a NO-OP apart from the side-effect of calling markAsDirty()
> Some other containers simply send out the destroy (valueUnbound etc) events for the oldValue in any case.
>
> Imo the spec doesn't define this clearly, so I'd like to hear the container vendors pov.
More clarity is good. I'm far less bothered about the details of how it
is clarified than I am that it is clarified. If my proposal above is
shot down in flames I'm fine with that as long as the spec ends up with
something that provides more clarity than we have now.
Mark
>
> From a Tomcat, Geronimo and TomEE pov it seems like perfectly fine. Older JBoss versions also worked that way afaik. As Glassfish is using Tomcat internally I guess it's also fine for it. I've not tested this with Undertow though, but Stu is on the list anyway so he can surely tell us.
> Would be great to get feedback from the other vendors as well.
>
>
> LieGrue,
> strub
>
>
>
>
>
>
>> On Monday, 9 February 2015, 14:44, Edward Burns <edward.burns_at_oracle.com> wrote:
>>> My pal Mark Struberg sent this to the users list moments ago and I feel
>> it is important to bring to the formal list. We've faced this problem
>> in JSF and have a brute force solution, but would welcome something
>> better. I don't have a good suggestion, though!
>>
>>>>>>> On Mon, 9 Feb 2015 13:06:14 +0000 (UTC), Mark Struberg
>> <struberg_at_yahoo.de> said:
>>
>> MS> I came across this a few times already and I think it's finally time
>> MS> to resolve the following underspecified behaviour.
>>
>> MS> Some servlet container support so called 'delta-replication'.
>> That
>> MS> means they only transfer session attributes to another cluster node
>> MS> if they got changed in a request (instead of always transferring ALL
>> MS> the session content to the other node/nodes). This is a nice feature
>> MS> as it sometimes helps to heavily reduce the network traffic.
>>
>> MS> The underspecified area is how to detect WHAT to transfer.
>>
>> MS> Tomcat e.g. only transfers attributes which got set via a
>> MS> Session#setAttribute() in the current request. Other containers have
>> MS> since mimicked this behaviour but still there are subtle
>> MS> differences.
>>
>> MS> The tricky point is how to tell the servlet container that some
>> MS> attributes needs to get transferred despite it's instance reference
>> MS> in the Sessions attribute map did not change at all.
>>
>> MS> E.g. consider a
>>
>> MS> List<PurchaseItem> shoppingCart = new ArrayList<>();
>> MS> session.setAttribute("shoppingcart", shoppingCart);
>>
>> MS> Now even if you change the content of the shoppingCart in subsequent
>> MS> requests the reference itself does NOT change. To tell Tomcat that
>> MS> this attribute still needs to be transferred in the
>> MS> delta-replication you have to invoke session.setAttribute again in
>> MS> those requests where you changed it's content.
>>
>> MS> I've seen this working pretty well but there are quite a few things
>> MS> which can get wrong.
>>
>> MS> E.g. Tomcat detects that setAttribute replaces 'itself' and thus
>> MS> suppresses the attribute 'destroyal'. Other containers just send
>> out
>> MS> all the events like HttpSessionBindingListener#valueUnbound, etc.
>>
>> JSF has an option com.sun.faces.enableAgressiveSessionDirtying (sic)
>> that does this for all JSF session scoped managed beans.
>>
>> MS> At the end I was not able to get delta-replication running portably
>> MS> across servers and had to switch the feature off in a few of them.
>>
>> MS> I'm not quite sure if delta-replication should get mentioned in the
>> MS> spec at all but maybe it's worth to at least unify the
>> 'destroyal'
>> MS> of attributes in such a case.
>>
>> MS> There are a few more subtle differences and maybe other users also
>> MS> have some quirks mode/hack/workaround to share.
>>
>> This is an ancient problem, I would expect others have solved it
>> already. Even though the set of solutions may include it, I think we
>> should not try to come up with some "automatic" solution. Rather,
>> consider if we can create an API for developers to call that advises the
>> Servlet that a particular entry in the session should be replicated.
>>
>> Ed
>>
>> --
>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>> | 20 days til DevNexus 2015
>> | 30 days til JavaLand 2015
>> | 40 days til CONFESS 2015
>>