[ 
https://issues.apache.org/jira/browse/GEODE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310905#comment-17310905
 ] 

ASF subversion and git services commented on GEODE-8671:
--------------------------------------------------------

Commit 35d230586db7d5a4eee8b91ee93ce0b4ee2c7c67 in geode's branch 
refs/heads/master from Jianxia Chen
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=35d2305 ]

GEODE-8671: Two threads calling get and retrieve the same PdxInstance, 
resulting in corruption (#5925)

For PdxInstance, return a new reference in LocalRegion.optimizedGetObject(), 
instead of using the value in the Future. This is to avoid Pdx corruption when 
multiple threads share the same reference of PdxInstance.

(cherry picked from commit dabb610b74bb0b27603d7803ec3cdd1cbb16c43f)


> Two threads calling get and retrieve the same PdxInstance, resulting in 
> corruption
> ----------------------------------------------------------------------------------
>
>                 Key: GEODE-8671
>                 URL: https://issues.apache.org/jira/browse/GEODE-8671
>             Project: Geode
>          Issue Type: Improvement
>          Components: regions
>            Reporter: Dan Smith
>            Assignee: Jianxia Chen
>            Priority: Major
>              Labels: blocks-1.14.0​, pull-request-available
>             Fix For: 1.12.2, 1.13.2, 1.14.0, 1.15.0
>
>
> Even if copy-on-read is set to true, two threads calling get on a partitioned 
> region can end up with the same PdxInstance object.
> This is problematic because some PdxInstances methods are not thread safe. 
> Although the underlying bytes are immutatable, the PDXInstance has a 
> ByteSource with a position field that changes. That means two threads doing 
> serialization or calling toString on the PdxInstance could result in one or 
> more threads getting a corrupt read.
> It looks like they are ending up with the same instance because of the 
> behavior in LocalRegion.optimizedGetObject. We use futures to make sure there 
> is only 1 get that goes through, and both threads receive the same value.
>     
> Ending up in optimizedGetObject requires a race with the put, because if the 
> value was in the cache at the beginning of the get it would be returned 
> earlier in the get process.
> I put a test that reproduces this issue here -   
> https://github.com/upthewaterspout/geode/pull/new/feature/pdx-instances-shared



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to