[jboss-user] [JBoss Cache: Core Edition] - Re: putForExternalRead doesn't solve our problem

[manik.surtani@jboss.com]

"jshowalter" wrote : 
  | We realize this is by design and documented as such, but the design puzzles us. The put should succeed if the node is there but the key for the data being put is missing, and should succeed if the node and key are there but the value in the node for that key is null.
  | 

The cache was designed to use a Node as a unit of atomicity and as such all loads, stores, locks, evicts, etc are all based on a node and not the contents of a node.  Nodes should only contain "related" data such that the above operations can happen on the node as a whole.

"jshowalter" wrote : 
  | Is our problem due to storing multiple items per node by key? If so, we could change to storing each item in a separate node. That seemed expensive (a lot of maps), but maybe that's how this is supposed to work?
  | 

Yes.  This is the way Hibernate does it, storing a single entity per Node (and using a dummy static "key").  Regarding the cost of this, this was addressed in JBCACHE-1082 which optimises nodes for single elements (using an internal SingletonMap where possible), so you need not worry about the performance impact too much.

"jshowalter" wrote : 
  | If so, we have a followup question--currently when we invalidate data locally (to force a cache miss and cache fill on the next access to that data), we just clear the data in a node, but leave the node in place. Are we supposed to invalidate by deleting the node itself? If so, how does *that* work when multiple threads are trying to access the same node? Won't readers back up behind a write lock, thereby re-introducing the very problem we were trying to solve with PFER in the first place? (Puts due to cache misses on reads timing out because of contention for write locks.)

Yes, you should remove the node.  Regarding locks, there is a cache option - lockParentForInsertRemove - which is off by default.  With this option being switched off, you don't have the problem of WL contention but you do introduce the possibility of phantom reads (but this is allowed in R_R semantics anyway).

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

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