[infinispan-issues] [JBoss JIRA] (ISPN-9107) IsolationLevel.READ_COMMITTED does not work as expected

[Tihomir Daskalov (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567901#comment-13567901 ] 

Tihomir Daskalov edited comment on ISPN-9107 at 4/27/18 2:51 AM:
-----------------------------------------------------------------

The configuration we use is visible in the attached test file. It is a standalone test that depends only on Infinispan and JUnit. 

We tested with local cache. Our application uses both clustered and local caches - depending on the application installation. We were not aware that READ_COMMITTED does not work in clustered environment (did not found this information in the Infinispan documentation). But, nevertheless, we tested the upgrade for now only with the local cache mode.

Our long-running transactions usually take 1-to-3 seconds. However, because of this issue, some of them now take over 20 seconds. This depends on when the transaction made cache lookup - before or after the other transaction has placed the value in it.

Our options for now are:
* Stay with Infinispan 7.2.4
* Upgrade Infinispan, but adapt the application to not rely on the READ_COMMITTED isolation level of Infinispan.
* Look for Infinispan alternative.

How can we perform the Infinispan reads outside a transaction when we are in a JavaEE XA transactional context?


was (Author: tisho2):
The configuration we use is visible in the attached test file. It is a standalone test that depends only on Infinispan and JUnit. 

We tested with local cache. Our application uses both clustered and local caches - depending on the application installation. We were not aware that READ_COMMITTED does not work in clustered environment (did not found this information in the Infinispan documentation). But, nevertheless, we tested the upgrade for now only with the local cache mode.

Our long-running transactions usually take 1-to-3 seconds. However, because of this issue, some of them now take over 20 seconds. This depends on when the transaction made cache lookup - before or after the other transaction has placed the value in it.

Our options for now are:
* Stay with Infinispan 7.2.4
* Upgrade Infinispan, but adapt the application to not rely on the READ_COMMITTED isolation level of Infinispan.
* Look for Infinispan alternative.

> 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)