Could someone from JBoss team comment on this topic please?
Is that correct behaviour in READ_COMMITED mode?
Is that incorrect cache usage?
Is that an issue with test (for example with DummyTrandactionManager)?
Is that an issue with cache itself?
Thanks!
View the original post :
Current transation can not see modifications done by committed transactions
while isolation level is READ_COMMITTED.
Cache version is 3.2.1.GA. Can be replicated when cache mode is REPL_SYNC or
INVALIDATION_SYNC (the other are not tested). Please see below test cases for
details.
Note: Test
As I understand your scenario is not primary use case for JBossCache. People
from Hibernate brought up this issue some time ago and as the result the method
putForExternalRead was added:
/**
| * Under special operating behavior, associates the value with the
specified key for a node
Hello.
Please see below test case. Currently working assertions are commented out. Is
that a bug? Cache version is 3.2.1.GA
| import java.util.ArrayList;
| import java.util.Collections;
| import java.util.List;
| import java.util.concurrent.CyclicBarrier;
| import
There is similar issue with REPL_SYNC. In this case it can be fixed by
commenting out begin/end calls in thread2. Is that an issue with
DummyTransactionManagerLookup or with cache itself?
| import java.util.ArrayList;
| import java.util.Collections;
| import java.util.List;
| import
Hi
As you can see from the below log:
* actual lock acquisition timeout in lockAndRecord is 10 seconds which equals
to timeout on the cache level. (time between MVCCLockManager.lockAndRecord and
MVCCLockingInterceptor.doAfterCall).
* the value of InvocationContext.getLockAcquisitionTimeout is
The version of the cache is 3.2.0.
The full subject is MVCCLockManager.lockAndRecord ignores the values of
InvocationContext.getLockAcquisitionTimeout
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4253536#4253536
Reply to the post :
