On 2/12/15, 10:12 AM, Edward Burns wrote:
> On 09/02/2015 13:42, Edward Burns wrote:
>
> EB> My pal Mark Struberg sent this to the users list moments ago and I feel
> EB> it is important to bring to the formal list.
>
>>>>>>>> On Mon, 9 Feb 2015 13:06:14 +0000 (UTC), Mark Struberg<struberg_at_yahoo.de> said:
> [...Mark describes the Deep Object Mutatinos and Session Replication problem]
>
> MS> There are a few more subtle differences and maybe other users also
> MS> have some quirks mode/hack/workaround to share.
>
> EB> This is an ancient problem, I would expect others have solved it
> EB> already. Even though the set of solutions may include it, I think we
> EB> should not try to come up with some "automatic" solution. Rather,
> EB> consider if we can create an API for developers to call that advises the
> EB> Servlet that a particular entry in the session should be replicated.
>
>>>>>> On Tue, 10 Feb 2015 08:03:56 +0000 (UTC), Mark Struberg<struberg_at_yahoo.de> said:
> MS> Kind of a touch(String attributeName) or markDirty(String attributeName)?
>
> MS> pro: more explicit
>
> MS> con: needs a new API.
>
> MS> The other option would be to define as standard what Tomcat does:
>
> [...Mark describes Tomcat's approach to the Deep Object Mutations and
> Session Replication problem.]
>
>>>>>> On Tue, 10 Feb 2015 15:19:36 +0000, Mark Thomas<markt_at_apache.org> said:
> MT> I think we should do a combination.
>
> MT> a) HttpSession.markAsDirty(String attributeName)
>
> MT> b) setAttribute() has an automatic side-effect of calling markAsDirty()
>
> MT> c) setAttribute() when the value is unchanged (i.e. the object being
> MT> passed is the same (read == ) as the object mapped to that attribute) is
> MT> a NO-OP apart from the side-effect of calling markAsDirty()
>
> MS> Currently the spec defines that setting a 'new' object means that
> MS> the 'old' object will get destroyed. The question now is what 'new'
> MS> means? In Tomcat this got interpreted as only account as 'new'
> MS> object if the newVal not equals the oldVal.
>
> MS> Some other containers simply send out the destroy (valueUnbound etc)
> MS> events for the oldValue in any case.
>
> MS> Imo the spec doesn't define this clearly, so I'd like to hear the
> MS> container vendors pov.
>
> MT> More clarity is good. I'm far less bothered about the details of how it
> MT> is clarified than I am that it is clarified. If my proposal above is
> MT> shot down in flames I'm fine with that as long as the spec ends up with
> MT> something that provides more clarity than we have now.
>
>>>>>> On Tue, 10 Feb 2015 14:45:02 +0000, Mark Thomas<markt_at_apache.org> said:
> MT> I've seen this requested many times too. There is an outstanding
> MT> enhancement request for this in Tomcat. How about:
>
> MT> HttpSession.markAsDirty(String attributeName)
>
> MT> We should clarify in the spec/Javadoc whether this means that the
> MT> container should act on this immediately (i.e. changes made in the
> MT> current request after this is called are not replicated) or if the
> MT> container should act on this when the request completes. My preference
> MT> is for the latter.
>
>>>>>> On Wed, 11 Feb 2015 17:59:16 +1100, Greg Wilkins<gregw_at_intalio.com> said:
> GW> The problem with just adding a new method is that it essentially leaves the
> GW> undefined behaviour of setAttribute as is. If an application was not
> GW> calling markAsDirty() then we would not know if that was because it didn't
> GW> know about the API or was it written expecting some funky session that auto
> GW> detects deep object mutations.
>
> Thank you for giving me a handle to describe this problem succinctly. I
> have updated the subject.
>
>>>>>> On Thu, 12 Feb 2015 12:53:13 +0000, Mark Thomas<markt_at_apache.org> said:
> MT> I addressed this in a different part of the thread (only on users I
> MT> think). We make it explicit that:
>
> [...Mark enumerates the above sketch]
>
> GW> If we really want to fix this, then perhaps we need modal behaviour: either
> GW> we work in the current ill defined API, where applications are essentially
> GW> tied to specific session implementations; or we enter a new mode with
> GW> precise portable cluster semantics - in which case we we may as well use an
> GW> entirely new API - or extension of the existing API.
>
> A non-novel approach we are using in JSF 2.3 is to look at the version
> number of the deployment descriptor as an explicit opt-in for all of the
> new features that have non-trivial behavior changes. We could do the
> same thing here. Obviously, this becomes an implementation and
> maintenance challenge, which argues for Greg's "new API" approach.
As I mentioned in the previous email, absence of deployment web.xml
descriptor means the latest version.
So, an old app may pick up the new behavior changes.
This may not be expected for an old app.
Shing Wai Chan
>
> GW> To repeat myself in a different way, we could have two session mechanisms
> GW> behind the same JSESSIONID tracking. If you call request.getHttpSession()
> GW> you get the old ill defined session. If you call
> GW> request.getDistributedSession() then you'd get the well defined cluster
> GW> session. You could even call both if you wanted to have some session
> GW> information held on the node and other in the cluster.
>
> GW> I think any attempt to slip good semantics under the existing session API
> GW> is going to break as many applications as it fixes.
>
> MT> Problems will occur when the new semantics are at odds with how a
> MT> container currently behaves. I think this can be addressed with
> MT> container specific options to restore the old behaviour for those apps
> MT> that have issues.
>
> MT> I'd rather clarify the current API and add a few container specific
> MT> options for backwards compatibility than add a whole new API.
>
> This is a very tricky one, but par for the course for Servlet 4.0. As
> with many other issues at this point in the JSR, we have two general
> approaches.
>
> DeepObjectMutations_evolution: I'll take Mark's a)b)c) sketch above as
> the starting point for this approach.
>
> DeepObjectMutations_new: I'll take Greg's idea as the starting point for
> this approach. This approach needs much more work to even reach the
> level of sketch.
>
> I'd like to have a better ability to weigh these approaches. Mark, your
> DeepObjectMutations_evolution sketch is a good starting point. Can we
> have some discussion here about what other side effects might be
> encountered with this approach? I am very sensitive to Greg's "break as
> many applications as it fixes" observation.
>
> Please do not bring any DeepObjectMutations_new ideas to this thread
> except to point out the perils of adopting
> DeepObjectMutations_evolution. After we have discussed
> DeepObjectMutations_evolution, we will have another thread about
> DeepObjectMutations_new.
>
> Thanks,
>
> Ed
>