[jboss-dev-forums] [Design of JBossCache] - Re: Gravitation and POJO Cache

[bstansberry@jboss.com]

Not every call; just gets.

The thing that makes autoDataGravitation=true really unworkable is that it causes a gravitation attempt any time a non-existent node is detected, whether for a read or a write.  So, add a new attribute to your session == do a gravitation check, since the put creates a new node.  Very non-performant. Having autoDataGravitation=false allows the app to decide when it's making a call that should result in gravitation.

Let me describe a bit about how FIELD session repl works. This seems kind of kludgy now, but anyway, here it is.

You have a node at /JSESSION/hostname/contextPath/sessionId that stores the session metadata in a couple key/value pairs. Plain cache functionality; not PojoCache.

Underneath that there is a child node for each session attribute.  Those are stored/retrieved using the PojoCache API.

When a request first comes in, the session manager sets the forceDataGravitation option and does a plain cache get on /JSESSION/hostname/contextPath/sessionId.  That will bring over the whole data structure, since the gravitation bring over the whole subtree under the requested Fqn.  That call is the only time data gravitation is allowed. It doesn't bring the relevant _JBossInternal_, the location of which is in a separate subtree at /JSESSION/hostname/contextPath/_JBossInternal_.

Where this breaks is when PojoCache needs to traverse a PojoReference to get to the _JBossInternal_ region.

Yeah, I guess in 2.0 there are more of those calls now, since everything is now stored in _JBossInternal_.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056711#4056711

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056711