jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [servlet-spec users] Re: Data Structures and Session Replication

From: Mark Thomas <markt_at_apache.org>
Date: Thu, 12 Feb 2015 12:53:13 +0000

On 11/02/2015 06:59, Greg Wilkins wrote:
>
> On 11 February 2015 at 01:45, Mark Thomas <markt_at_apache.org
> <mailto:markt_at_apache.org>> wrote:
>
> HttpSession.markAsDirty(String attributeName)
>
>
> The problem with just adding a new method is that it essentially leaves
> the undefined behaviour of setAttribute as is. If an application was
> not calling markAsDirty() then we would not know if that was because it
> didn't know about the API or was it written expecting some funky session
> that auto detects deep object mutations.

I addressed this in a different part of the thread (only on users I
think). We make it explicit that:

* setAttribute() has an automatic side-effect of calling markAsDirty()

* 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()

> If we really want to fix this, then perhaps we need modal behaviour:
> either we work in the current ill defined API, where applications are
> essentially tied to specific session implementations; or we enter a new
> mode with precise portable cluster semantics - in which case we we may
> as well use an entirely new API - or extension of the existing API.
>
> To repeat myself in a different way, we could have two session
> mechanisms behind the same JSESSIONID tracking. If you call
> request.getHttpSession() you get the old ill defined session. If you
> call request.getDistributedSession() then you'd get the well defined
> cluster session. You could even call both if you wanted to have some
> session information held on the node and other in the cluster.
>
> I think any attempt to slip good semantics under the existing session
> API is going to break as many applications as it fixes.

Problems will occur when the new semantics are at odds with how a
container currently behaves. I think this can be addressed with
container specific options to restore the old behaviour for those apps
that have issues.

I'd rather clarify the current API and add a few container specific
options for backwards compatibility than add a whole new API.

Mark