[infinispan-issues] [JBoss JIRA] (ISPN-9107) IsolationLevel.READ_COMMITTED does not work as expected
Pedro Ruivo (JIRA)
issues at jboss.org
Fri Apr 27 09:15:00 EDT 2018
[ https://issues.jboss.org/browse/ISPN-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13568165#comment-13568165 ]
Pedro Ruivo commented on ISPN-9107:
-----------------------------------
Hi [~tisho2],
Local caches should work as expected. No idea why your test isn't work. We have a similar test here: [code|https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/mvcc/read_committed/ReadCommittedLockTest.java#L17].
I'll replicate your test in our test suite and check what is failing.
About the clustered caches, (if I recall correctly) it was a performance optimisation to avoid the cost of a remote call to check the last committed value.
TBH, there was a discussion about the removal of READ_COMMITTED (https://issues.jboss.org/browse/ISPN-3927).I guess we need to discuss it again :)
bq. How can we perform the Infinispan reads outside a transaction when we are in a JavaEE XA transactional context?
AFAIK, you can suspend the transaction via cache.getAdvancedCache().getTransactionManager().suspend(), perform the read, and resume it again.
> IsolationLevel.READ_COMMITTED does not work as expected
> -------------------------------------------------------
>
> Key: ISPN-9107
> URL: https://issues.jboss.org/browse/ISPN-9107
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.0.1.Final, 9.2.1.Final
> Reporter: Tihomir Daskalov
> Attachments: InfinispanTest.java
>
>
> We use Infinispan in JBoss EAP 7.0.9 as separate module. We use it in TRANSACTIONAL mode with READ_COMMITTED isolation level. After we upgraded Infinispan from 7.2.4 to 9.2.1, we notice that Infinispan does not obey the isolation level. It always behaves as REPEATABLE_READ.
> I see a similar issue in ISPN-1340 that is rejected with the argument that REPEATABLE_READ is a stronger isolation level than READ_COMMITTED and thus the later is not really needed.
> I see this as a feature loss. Our application has long-running transactions that only read from the cache and short-running transactions that read and write. This bug causes the long-running transactions to not see the changes from the short-running transactions. So, they do not profit from the cache and are slower.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
More information about the infinispan-issues
mailing list