cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrus Adamchik (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAY-2123) Synchronizing cache updates with external trasnaction boundaries
Date Mon, 17 Oct 2016 11:57:58 GMT

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

Mime
View raw message