JBossDeveloper

Manik,

Your explanation makes sense, however I wonder whether that means Hibernate / Hib-JBC2 integration project / JBC3 stack is unusable with REPEATABLE_READ then. Let me explain.

Person, Child are cached entities, parent.children is a cached collection (using Hibernate's Transactional concurrency strategy).

Consider this method:

public void addChild(parentId){

tx.begin();

Parent p = parentDAO.get(parentId);
Set<Child> children = p.getChildren();
Child newChild = new Child();
children.add(newChild);
tx.commit();
}

package org.jboss.cache.api;

import org.jboss.cache.config.Configuration;
import org.jboss.cache.config.Configuration.NodeLockingScheme;
import org.jboss.cache.factories.UnitTestConfigurationFactory;
import org.testng.annotations.Test;

import javax.transaction.TransactionManager;

import org.jboss.cache.*;
import org.jboss.cache.lock.IsolationLevel;

/**
 * Tests that a node that was putFromExternalRead and then removed in TX1 does NOT
 * get returned in subsequent TX2.
 *
 * @author nikita_tovstoles@mba.berkeley.edu
 * @since 3.0.3.GA
 */
@Test(groups = {"functional", "pessimistic"}, sequential = true, testName = "api.RemovedNodeResurrectionInSubsequentTxTest")
public class RemovedNodeResurrectionInSubsequentTxTest extends AbstractSingleCacheTest {

 private static final Fqn A_B = Fqn.fromString("/a/b");
 private static final Fqn A = Fqn.fromString("/a");
 private static final Fqn A_C = Fqn.fromString("/a/c");
 private static final String KEY = "key";
 private static final String VALUE = "value";
 private static final String K2 = "k2";
 private static final String V2 = "v2";
 protected NodeSPI root;
 protected TransactionManager txManager;

 public CacheSPI createCache() {
 CacheSPI myCache = (CacheSPI<Object, Object>) new UnitTestCacheFactory<Object, Object>().createCache(UnitTestConfigurationFactory.createConfiguration(Configuration.CacheMode.LOCAL, false), false, getClass());
 myCache.getConfiguration().setCacheMode(Configuration.CacheMode.LOCAL);
 myCache.getConfiguration().setCacheLoaderConfig(null);
 myCache.getConfiguration().setNodeLockingScheme(NodeLockingScheme.MVCC);
 configure(myCache.getConfiguration());
 myCache.start();
 root = myCache.getRoot();
 txManager = myCache.getTransactionManager();

 return myCache;
 }

 protected void configure(Configuration c) {
 c.setIsolationLevel(IsolationLevel.REPEATABLE_READ);
 }

 public void testPferAndEvictInSameTx() throws Exception {

 Object val = null;

 cache.getRoot().addChild(A);

 txManager.begin();

 val = cache.get(A_B, KEY); //N1 IF THIS LINE IS EXECUTED, TEST FAILS BELOW AT N2

 //put in cache
 cache.putForExternalRead(A_B, KEY, VALUE);

 //val = cache.get(A_B, KEY);
 //assert val != null : "get() after pfer() returned " + val; //N2 THIS WILL FAIL IF LINE N1 (ABOVE) IS EXECUTED (NOT COMMENTED OUT)

 //evict from cache
 cache.removeNode(A_B); //sometimes MVCCInvocationContext has ref to mvccTCtx, sometimes NOT

 //verify eviction
 //val = cache.get(A_B, KEY);
 //assert val == null : "get() after evict() returned " + val;

 txManager.commit();

 txManager.begin();
 //verify miss
 val = cache.get(A_B, KEY);
 assert val == null : "get() after tx.commit returned " + val;

 txManager.commit();

 }
}

java.lang.AssertionError: get() after tx.commit returned value
at org.jboss.cache.api.RemovedNodeResurrectionInSubsequentTxTest.testPferAndEvictInSameTx(RemovedNodeResurrectionInSubsequentTxTest.java:78)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

I am unsure what "inconsistency" means as relating to whether the software works as designed, but IMO this is a bug in the hib-jbc2 integration layer. Please note that if cache.evict() were used instead of removeNode() same problem would arise.

Note that the workaround involved not only using READ_COMMITTED in jbc config but also ensuring that Datasource being enlisted as XA Resource was configured to READ_COMMITTED as well.

Manik,

Thanks for posting the JIRA. However, at the risk of appear to be a nit-picker, I don't think JBCACHE-1493 captures the extent of the problem as it pertains to R_R, and Hibernate - JBC3 interaction. Specifically, given an application that uses Hibernate and JBC3 (MVCC) as 2nd level cache in Transactional (as opposed to read-only) mode:
1. the pattern I described in the post linked below is not an edge case:
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217616#4217616
Basically, this will take place whenever app logic is such that the 1st time a collection is accessed the intent is to alter it.
2. as far as I can tell, enabling writeSkewCheck will merely result in data version exceptions being thrown in this use case - making collection un-cacheable if app does a write on 1st access.

Given the above pattern, and sequence of calls that HIbernate Core issues in case of Collections I think the solution is not to use pfer() in org.hibernate.cache.jbc2.collection.TransactionalAccess.putFromLoad() if R_R is in use.

-nikita

I see. Makes sense.

Can you comment more on why making the datasource READ_COMMITTED as well was necessary?

I am using mysql 5.1 with INNODB. the db reports iso as RR