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.
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
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 17 days til DevNexus 2015
| 27 days til JavaLand 2015
| 37 days til CONFESS 2015