[jboss-dev-forums] [Design of JBossCache] - Re: Removing classloader issues for PojoCache

bstansberry@jboss.com do-not-reply at jboss.com
Tue Oct 2 16:29:26 EDT 2007


Chat history related to above:

anonymous wrote : 
  | [14:43:27] Jason T. Greene: did you ever review my reply to the marshalvalue thread?
  | [14:48:01] Brian Stansberry: i was a little unclear on #2; i.e. when the deserialization occurs and what gets passed to the callback
  | [14:50:15] ? i.e. how it would be different from the current region-based marshalling
  | [14:51:07] Jason T. Greene: it would just keep you from having to configure the region up front
  | [14:51:27] ? and allow for you to make decisions at the node level
  | [14:52:03] Brian Stansberry: ok, ic.
  | [14:52:17] ? here's a sucky thing about region-based....
  | [14:52:45] ? for a tx prepare, we need to figure out the region
  | [14:53:10] ? we do that by checking the first method call in the set of method calls that make up the prepare
  | [14:53:25] ? if a tx spans classloader regions, that breaks
  | [14:54:24] ? i suppose a serialization manager could be more intelligent
  | [14:54:44] Jason T. Greene: hmm shouldnt prepare deseralize each call separately according to the fqn
  | [14:54:45] ? ?
  | [14:55:41] Brian Stansberry: yeah, that would be better. DOH!
  | [14:56:22] ? just serialize the elements individually and then wrap them up in the prepare method call
  | [14:57:11] Jason T. Greene: yeah you could even do this intelligently with markers that prevent double buffering
  | [14:59:40] Jason T. Greene: so the serialization manager suggestion was really because i was interpreting the problem being allocating the structure to fit the region model
  | [15:01:01] Brian Stansberry: well, its more than that
  | [15:01:18] ? assume the goal is to fit all session repl in a shared cache
  | [15:02:03] ? for most usages, the session is represented by a single key/value pair in one node.
  | [15:02:53] ? and most txs involve changing a single session
  | [15:03:13] ? for that case, a wrapper obj is more efficient than passing a region-fqn as external metadata for every call
  | [15:04:36] Jason T. Greene: ok so the issue is multiple classloaders in the same session right?
  | [15:05:03] Brian Stansberry: no, multiple classloaders in the same cache; only one per session
  | [15:05:27] ? I can either use something like region-based marshalling or wrap the cached objects
  | [15:05:38] Jason T. Greene: oh i see
  | [15:05:50] ? now i get what you are talking about
  | [15:06:27] ? technically the region-fqn is duplicate information
  | [15:06:38] ? you already know the region from the fqn
  | [15:06:38] Brian Stansberry: yes
  | [15:07:27] ? yes, although the Fqn is encapsulated as an arg in the MethodCall, and which arg depends on the method
  | [15:08:12] ? also, an element of the fqn can itself be a custom type, as long as its below the region root
  | [15:08:40] ? BTW that's an issue with Hibernate caching (which is a quite different use case)
  | [15:10:43] Jason T. Greene: the first problem is an issue with the serialization format
  | [15:10:54] ? the second is bigger problem
  | [15:11:21] Brian Stansberry: +1
  | [15:16:17] Jason T. Greene: I want to get rid of that usage in pojo cache
  | [15:16:41] Brian Stansberry: which?
  | [15:16:49] Jason T. Greene: custom types in an fqn
  | [15:16:59] ? its used for maps right now
  | [15:17:39] Brian Stansberry: the key for a map entry is the last Fqn element?
  | [15:18:09] Jason T. Greene: yeah, it was done that way to make locking more efficient
  | [15:18:29] ? and index retrieval is effecient as well
  | [15:19:34] ? what i probably want to do is keep it like that for simple types
  | [15:19:55] ? but when a custom type is used generate a hash based UUID
  | [15:21:39] ? anyway its a problem i have to think about
  | [15:21:48] ? because their are other issues with custom fqns
  | [15:21:53] ? like cache loaders

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

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



More information about the jboss-dev-forums mailing list