"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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...