[jboss-jira] [JBoss JIRA] (WFLY-7127) CMR collection gets corrupted in 2LC on certain concurrent access

[Gail Badner (JIRA)]

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

Gail Badner edited comment on WFLY-7127 at 11/2/16 5:17 PM:
------------------------------------------------------------

[~zds], thanks for your test case. I have confirmed that your test uses TRANSACTIONAL cache concurrency strategy (not READ_ONLY). I have reproduced your issue using MySQL.

I believe there are some differences between the ear in your attachment and the ear that is generated using `ant build`. I also don't see anything that configures the CMR. I could be missing something there. Can you point out what it is in your attachment that configures the CRM.


was (Author: gbadner):
@reporter, thanks for your test case. I have confirmed that your test uses TRANSACTIONAL cache concurrency strategy (not READ_ONLY). I have reproduced your issue using MySQL.

I believe there are some differences between the ear in your attachment and the ear that is generated using `ant build`. I also don't see anything that configures the CMR. I could be missing something there. Can you point out what it is in your attachment that configures the CRM.

> CMR collection gets corrupted in 2LC on certain concurrent access
> -----------------------------------------------------------------
>
>                 Key: WFLY-7127
>                 URL: https://issues.jboss.org/browse/WFLY-7127
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, JPA / Hibernate, Transactions
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu Linux 15.10. Java 1.8.0_66
>            Reporter: Jari Juslin
>            Assignee: Scott Marlow
>         Attachments: infinispan_cmr_corruption_repro.tar.gz, standalone.xml
>
>
> With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted.
> Steps to reproduce:
> 1) Make sure the CMR collection is not in cache.
> 2) Start a read-only transaction accessing the said collection.
> 3) In a separate transaction delete an element from that collection.
> 4) End the read-only transaction.
> 5) Read the resulting collection. It now throws EntityNotFoundException.
> My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC.
> Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB.
> For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern.
> The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)