[
https://issues.apache.org/jira/browse/OFBIZ-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14044331#comment-14044331
]
Adam Heath commented on OFBIZ-5534:
-----------------------------------
Ok. I've got an implementation that works, sorta, locally. All existing test
cases pass. I then applied the patch(which still had no offsets/conflicts with
trunk). And got an error.
In the comments for service T2, there is a commented out block, that mentions a
dead-lock occurring on derby. This is because thread T1 has created a new
value(12345) inside a transaction, which hasn't yet been commited to the
database. Then, in thread T2, an attempt to read that value occurs. But since
it hasn't yet been committed, you would think that derby would return no
result. I haven no idea why it blocks, waiting on the other transaction. I
might consider this a bug in derby.
Basically, my change, is to detect that a transaction is active, and disable
all cache reads; basically, all the read methods org.ofbiz.entity.cache.Cache
return null. Then, all put/remove methods in that same class are delayed, and
are run at the end of the transaction(by making use of a Synchronization).
> Dirty reads from entity cache
> -----------------------------
>
> Key: OFBIZ-5534
> URL: https://issues.apache.org/jira/browse/OFBIZ-5534
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04,
> Release Branch 13.07
> Reporter: Jacopo Cappellato
> Assignee: Adam Heath
> Attachments: unittest-dirtyreadsfromcache.patch
>
>
> Even if database transaction isolation level is set to "ReadCommitted", a
> transaction can get uncommitted records from the entity cache, under certain
> circumstances.
> Here is a test case:
> 1) transaction T1 creates a record
> 2) T1 calls findOne to retrieve it: the read will be successful (because T1
> can read data generated in T1 even if not committed) and the record will be
> added to the cache
> 3) T1 calls another service with requireNewTransaction set to true: this will
> run the second service in a new transaction T2
> 4) T2 calls findOne to retrieve the record created by T1: if useCache is set
> to false it should fail; if useCache is set to true it will succeed (getting
> the record from cache, even if the data is not committed to the db)
> The result in #4 is wrong because T2 should not see the uncommitted record
> We should never add uncommitted records to the entity cache.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
