Scoping of FIELD granularity session pojos

[brian.stansberry]

Currently, pojos stored in a FIELD replication granularity web session are stored in a section of the cache scoped to the webapp, not to the session. I'm more and more inclined to change this to session scoping, and would appreciate any comments anyone may have.

Allowing different sessions to share pojos has a fundamental drawback, plus it introduces a number of implementation hassles:

Fundamental drawback is users running on different nodes can attempt to concurrently modify the pojo. This can lead to anomalous behavior or distributed deadlocks

Implementation hassles:

1) Can't passivate pojos along with sessions. Making them sharable gives them an independent lifecycle, so they can't be stored in the cache in the subtree belonging to a particular session. So, evicting a session's subtree doesn't remove the pojos. Leads to the need for a very hacky and imprecise introduction of raw JBC node eviction concepts into jboss-web.xml to let users configure pojo eviction.

2) Data gravitation. Again, sharable pojos can't be stored under a session's subtree. So, gravitating that subtree following failover doesn't bring the associated pojos. That has to be managed separately, and requires telling PojoCache to always do a data gravitation check any time it doesn't find something in the cache. That's inefficient when new objects are inserted. Plus I haven't gotten it work properly yet now that PC no longer does it by default. ;)

3) Ownership with buddy replication. Related to data gravitation. If a pojo is shared and the sessions sharing it end up on different nodes, the shared pojo will start getting gravitated back and forth between between the nodes. This is contrary to the whole idea of buddy replication, which is that data is owned by own node and only moves to handle failover.


Possible solutions:

1) Store pojos under the session that first passes them to setAttribute.

Pros: solves above problems

Cons: if webapp stores the same pojo under two different sessions, PC will support this. But if the first session is removed, the underlying pojo will be removed with it and if the second session tries to use it they will get an exception.

2) Make it configurable via a pojo-scope element in jboss-web.xml, valus are APPLICATION or SESSION, default is session.

Basically, still support the existing behavior. Log a WARN if user specifies ATTRIBUTE with a buddy replication cache.

Pros: give people who count on current behavior a way out.

Cons: ignores the "fundamental problem" discussed above. Requires supporting the hacky JBC eviction configuration via jboss-web.xml stuff.

Comments?

[jason.greene]

1) Store pojos under the session that first passes them to setAttribute.

Pros: solves above problems

Cons: if webapp stores the same pojo under two different sessions, PC will support this. But if the first session is removed, the underlying pojo will be removed with it and if the second session tries to use it they will get an exception.

Are you just referring to making every session a region? This would still have problems with gravitation, since a shared pojo would either bounce back and forth if we always force gravitation, or if we don't might not be accessable . Unless of course you can gaurantee that all sessions associated with a web app are all located on the same node.

2) Make it configurable via a pojo-scope element in jboss-web.xml, valus are APPLICATION or SESSION, default is session.

Basically, still support the existing behavior. Log a WARN if user specifies ATTRIBUTE with a buddy replication cache.

IMO if we are going to share pojos and bind them to a special region, then we should make that region not use buddy replication (if possible).

[brian.stansberry]

1) Store pojos under the session that first passes them to setAttribute.

Pros: solves above problems

Cons: if webapp stores the same pojo under two different sessions, PC will support this. But if the first session is removed, the underlying pojo will be removed with it and if the second session tries to use it they will get an exception.

Are you just referring to making every session a region? This would still have problems with gravitation, since a shared pojo would either bounce back and forth if we always force gravitation, or if we don't might not be accessable . Unless of course you can gaurantee that all sessions associated with a web app are all located on the same node.

Yes, every session is a region. Essentially this would mean saying shared pojos are not supported, since invalidating a session will remove the pojos out from underneath all the other sessions. My "Con" above refers to the fact that if people try to share pojos or do it accidentally, we can't detect that right away -- the call to attach() with an fqn for the 2nd session will work and create a PojoReference pointing to the _JBossInternal_ region under the first session.

IMO if we are going to share pojos and bind them to a special region, then we should make that region not use buddy replication (if possible).

Yes. Logically, if you want to share objects between sessions, the place to put them is in the ServletContext. There's a JIRA to make that clustered. A clustered ServletContext cache wouldn't use buddy replication.

[brian.stansberry]

I'll bring up this general topic when we talk Monday AM.

Plus I haven't gotten it work properly yet now that PC no longer does it by default. ;)

This was fixed yesterday. Gravitating pojos from the shared region now works, for good or ill, as it did in AS 4.

My "Con" above refers to the fact that if people try to share pojos or do it accidentally, we can't detect that right away -- the call to attach() with an fqn for the 2nd session will work and create a PojoReference pointing to the _JBossInternal_ region under the first session.

Can PC provide some sort of utility method to tell me where the ref to an object is stored? Or something that tells me if a ref to it is stored in a given region? E.g. I would have code like this:

Fqn sess2Region = getRegionFqn(sess2);
if (PojoCacheUtil.isCachedInOtherRegion(pojo, sess2Region)) {
 throw new IllegalStateException("Object " + pojo + " is already stored in another session; sharing objects between sessions is not supported");
}

I could perhaps implement that by looking for a PC interceptor and checking its getFqn() method, but that's a bad idea. :)

[galder.zamarreno]

Brian,

1) Store pojos under the session that first passes them to setAttribute.

Looks fine as long as you do it starting with JBoss 5. It's a major release, so you could get away with breaking as long as it's noted somewhere clearly and we've got easy access to it.

2) Make it configurable via a pojo-scope element in jboss-web.xml, valus are APPLICATION or SESSION, default is session.

I don't think we should try to leave something in that we don't wanna be supporting for JBoss 5. I like this solution for a potential future 4.x release.

Logically, if you want to share objects between sessions, the place to put them is in the ServletContext. There's a JIRA to make that clustered. A clustered ServletContext cache wouldn't use buddy replication.

Interesting. Bearing in mind that my web development knowledge is a bit vague (side note: just to give you an idea: I was banging my head the other day because I was trying to access a servlet I deployed but kept getting a 404. I had forgotten the servlet mapping, doh!), seems like sharing objects between sessions via HTTPSession is a bad idea anyway, so this is an extra motivation to go for 1. IOW, if someone says it breaks, we can say it's a bad practice anyway.

So, my opinion would be to go with 1 and implement sharing of pojos properly via the servlet context.

[vblagojevic]

I don't think we should try to leave something in that we don't wanna be supporting for JBoss 5. I like this solution for a potential future 4.x release.

I agree with Galder.

[brian.stansberry]

OK, so far no one particularly likes the "configurable" idea -- myself included. :-)

As for a future JBoss 4.x, well, any volunteers? ;)

[brian.stansberry]

http://jira.jboss.com/jira/browse/JBAS-5618