[jira] [Updated] (CAY-2123) Synchronizing cache updates with external trasnaction boundaries

["Andrus Adamchik (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAY-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrus Adamchik updated CAY-2123:
---------------------------------
    Description: 
Some of the steps in the commit sequence should work differently when Cayenne is operating under external transactions. One scenario is shared cache synchronization. E.g.:

1. Thread A commits ObjectContext. Under external transaction this results in a flush operation, pending tx commit/rollback
2. Thread B runs an operation that hits the cache (e.g. reads a to-one relationship). It gets values committed under thread A, but not yet visible in the DB (an example of dirty read ... wrong behavior already).
3. Thread A rolls back its transaction... Invalid value gets stuck in shared cache for all other threads to see.

This behavior results in dirty reads regardless of the actual transaction isolation level. Looks like we'll need to make our cache transaction-aware and provide an API for committing cache state on external transaction events. The initial implementation for this API may be targeting Spring transactions.

Things may become even more complicated when multiple overlapping threads change the same object. "snapshot version changed" message in the logs is a symptom of this inconsistency. 


  was:
Some of the steps in the commit sequence should work differently when Cayenne is operating under external transactions. One scenario is shared cache synchronization. E.g.:

1. Thread A commits ObjectContext. Under external transaction this results in a flush operation, pending tx commit/rollback
2. Thread B runs an operation that hits the cache (e.g. reads a to-one relationship). It gets values committed under thread A
3. Thread A rolls back its transaction... Invalid value gets stuck in shared cache. Now all threads will see it.

This behavior results in dirty reads regardless of the actual transaction isolation level. Looks like we'll need to make our cache transaction-aware and provide an API for committing cache state on external transaction events. The initial implementation for this API may be targeting Spring transactions.

Things may become even more complicated when multiple overlapping threads change the same object. "snapshot version changed" message in the logs is a symptom of this inconsistency. 



> Synchronizing cache updates with external trasnaction boundaries
> ----------------------------------------------------------------
>
>                 Key: CAY-2123
>                 URL: https://issues.apache.org/jira/browse/CAY-2123
>             Project: Cayenne
>          Issue Type: Bug
>    Affects Versions: 3.1.1, 4.0.M3
>            Reporter: Andrus Adamchik
>            Assignee: Andrus Adamchik
>
> Some of the steps in the commit sequence should work differently when Cayenne is operating under external transactions. One scenario is shared cache synchronization. E.g.:
> 1. Thread A commits ObjectContext. Under external transaction this results in a flush operation, pending tx commit/rollback
> 2. Thread B runs an operation that hits the cache (e.g. reads a to-one relationship). It gets values committed under thread A, but not yet visible in the DB (an example of dirty read ... wrong behavior already).
> 3. Thread A rolls back its transaction... Invalid value gets stuck in shared cache for all other threads to see.
> This behavior results in dirty reads regardless of the actual transaction isolation level. Looks like we'll need to make our cache transaction-aware and provide an API for committing cache state on external transaction events. The initial implementation for this API may be targeting Spring transactions.
> Things may become even more complicated when multiple overlapping threads change the same object. "snapshot version changed" message in the logs is a symptom of this inconsistency. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)