[jbosscache-dev] Problems with node locking semantics in JBC 1.4.1.GA

Brian Stansberry brian.stansberry at jboss.com
Sun Jan 28 15:38:46 EST 2007


In 1.4.1.GA, we introduced node locking semantics that weren't there in
the previous few releases (and maybe never were there).  This is causing
significant integration issues.

Specifically, before inserting or removing a child node, we acquire a WL
on the parent.  Previously, only a RL was acquired.

I'm concerned about anomalies this might cause in apps that
intentionally or unintentionally depends on the old behavior. For
example, the AS http session repl code assumes it has freedom to
add/remove cache nodes that represent a session underneath the parent
that represents the webapp. Now these activities will block until any
activity on any other session is complete.  With FIELD granularity,
that's a big issue, as locks are held throughout the web request. It
will likely cause issues with other granularities as well. (We already
saw a minor issue in a support case when a customer tried to upgrade
4.0.5 to 1.4.1).

This definitely breaks the Hibernate (and thus EJB3 entity bean
clustering) integration with 1.4.1.GA. Basically, assume there is an
entity Person, with a child collection "children".  Hibernate caches the
entity, and later caches the child collection in a child node.

1) Transaction tx = tm.begin();
2) cache.get("/Person/Person#1/children", ITEM); // returns null -- not
cached yet

3) read db to get the ids of the collection elements

4) tx.suspend();
5) cache.putFailFast("/Person/Person#1/children", ITEM, data);
6) tx.resume();

This fails in step 5, because with the tx suspended, the putFailFast()
call cannot acquire the WL on /Person/Person#1 that it needs to insert
/Person/Person#1/children.

Hmm, an EJB3 unit test shows that problem occuring, but I assume even
simple entity caching will break:

1) Transaction tx = tm.begin();
2) cache.get("/Person/Person#2", ITEM); // returns null -- not cached
yet

3) read db to get the Person

4) tx.suspend();
5) cache.putFailFast("/Person/Person#1", ITEM, data);
6) tx.resume();

We need a quick workaround for this in the 1.4 branch, as it's a blocker
for EJB3 RC10 and AS 4.2.

Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry 




More information about the jbosscache-dev mailing list