[jboss-user] [JBossCache] - Re: Cache v2.0 Alpha2: Optimistic Locking + Explicit Version
chasta
do-not-reply at jboss.com
Thu Jan 18 08:18:53 EST 2007
Hmmm. While trying to create a unit test method for you (for the latest version from CVS), I wrote the following method (added to ExplicitVersionsTest):
| Node root = cache.getRoot();
|
| TestVersion lev2V = new TestVersion("Lev2-v");
| cache.getInvocationContext().getOptionOverrides().setDataVersion(lev2V);
| root.addChild(Fqn.fromString("LEV2"));
|
| Node lev2 = root.getChild(Fqn.fromString("LEV2"));
|
| TestVersion lev3V = new TestVersion("Lev3-v");
| cache.getInvocationContext().getOptionOverrides().setDataVersion(lev3V);
| lev2.addChild(Fqn.fromString("LEV3"));
|
| Node lev3 = lev2.getChild(Fqn.fromString("LEV3"));
|
| if (lev3 == null)
| throw new Exception("Hay! lev3 is null!");
|
| TestVersion lev4V = new TestVersion("Lev4-v");
| cache.getInvocationContext().getOptionOverrides().setDataVersion(lev4V);
| lev3.addChild(Fqn.fromString("LEV4"))
|
The null check for lev3 was added because it is indeed null and the test fails because of that; that seems strange, and was not the behavior I was trying to reproduce...
After commenting out the explicit-versioning related code, everything seemed to work normally; lev3 was not null...
| Node root = cache.getRoot();
|
| // TestVersion lev2V = new TestVersion("Lev2-v");
| // cache.getInvocationContext().getOptionOverrides().setDataVersion(lev2V);
| root.addChild(Fqn.fromString("LEV2"));
|
| Node lev2 = root.getChild(Fqn.fromString("LEV2"));
|
| // TestVersion lev3V = new TestVersion("Lev3-v");
| // cache.getInvocationContext().getOptionOverrides().setDataVersion(lev3V);
| lev2.addChild(Fqn.fromString("LEV3"));
|
| Node lev3 = lev2.getChild(Fqn.fromString("LEV3"));
|
| if (lev3 == null)
| throw new Exception("Hay! lev3 is null!");
|
| // TestVersion lev4V = new TestVersion("Lev4-v");
| // cache.getInvocationContext().getOptionOverrides().setDataVersion(lev4V);
| lev3.addChild(Fqn.fromString("LEV4"))
|
Am I using the API incorrectly, or is this indeed a bug? I didn't yet manage to reproduce the same bug, but perhaps this is related... I guess in our application some other factor also takes a role in the failure.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003294#4003294
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003294
More information about the jboss-user
mailing list