[jboss-dev-forums] [Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

"jason.greene(a)jboss.com" wrote : Thats not a deadlock, the updates would be serialized though. Sure you can deadlock. When I said "node A" and "node B" I meant different cache instances in the cluster. The both acquire local write locks on the same node in the tree, insert/update their key, then try to acquire the WL globally as part of tx commit. Fails. Assume pessimistic locking here (which may not be an issue if we do this far enough in the future, but partly I'm thinking about whether I want to try it this way now.) anonymous wrote : I believe this can be solved by modifying putForExternalRead to not only check for node existence, but also key existence. Yeah, that's the solution; just not sure how simple that is, since once you start looking inside nodes you might have to start thinking about locking issues etc that don't exist if you just check node existence. But, it might be trivial. anonymous wrote : In the 2 node solution, which does not seem necessary, the UUID does not need to be known by all nodes. It is generated once, for the entire lifespan of the second node. Let's pretend a bit that the 2 node solution is necessary, in case it leads somewhere. :) You can have concurrent putForExternalRead calls on different cache instances, each of which would store a different UUID for the same entity. You'd end up with two copies of the entity in the cache. Hmm -- actually you'd get a weird effect where the PFER call for inserting the key/uuid would be aborted when propagated (since the key already exists on the remote node) but the PFER for the uuid node would succeed. OK, let's ignore the 2 node solution. ;) Lot's of problems like that; weirdness when Hibernate suspends transactions, but now we're dealing with doing multiple cache writes. anonymous wrote : Keep them coming! With OL, we'd have versioning problems, since the version is applied to the node, not the key/value pair. 2 node solution rises from the dead.... Architecturally, probably cleaner to have a cache per SessionFactory, with the default classloader for deserialization being the deployment's classloader. Seems the only negative to that is if a tx spans session factories, which is probably not a common case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117754#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...