[hibernate-issues] [Hibernate-JIRA] Reopened: (HHH-3817) JBC second level cache integration can cache stale collection data

[Brian Stansberry (JIRA)]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reopened HHH-3817:
-----------------------------------


Galder has found some issues with the fix for this, basically:

1) T1 does a get(), registers and pending put
2) T1 reads db
3) T1 calls putFromLoad, which successfully calls PutFromLoadValidator.isPutValid()
4) T2 changes the collection, remove is called on the cache
5) T1's call to putFromLoad progresses, actually writes to the cache -- with stale data

Solution is to use locking such that step 3 acquires a lock, step 5 releases lock, step 4 also needs to acquire lock. This will force step 4 after step 5.

> JBC second level cache integration can cache stale collection data
> ------------------------------------------------------------------
>
>                 Key: HHH-3817
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3817
>             Project: Hibernate Core
>          Issue Type: Bug
>          Components: caching (L2)
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 3.5.0-CR-2
>
>
> Scenario with two transactions dealing with a single collection:
> tx1 reads collection, cache miss
> tx1 goes to database to read collection
> tx2 reads collection, cache miss
> tx2 goes to database to read collection
> tx2 does JBC putForExternalRead to store empty collection
> tx2 updates collection
> tx2 removes collection from JBC (since any collection update triggers a org.hibernate.cache.Cache.evict which is implemented as a JBC removeNode)
> tx1 does JBC putForExternalRead to store empty collection -- STALE DATA
> With entities, if the db is using REPEATABLE_READ this won't be a problem, as the DB won't allow the tx2 update until tx1 commits.  With a collection there is nothing to lock on. It would be a problem for entities with READ_COMMITTED as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira