[jira] [Updated] (OPENJPA-2792) Race condition in using compatibility flags (turns on cascade on detach)

["Pawel Veselov (JIRA)" <ji...@apache.org>]

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

Pawel Veselov updated OPENJPA-2792:
-----------------------------------
    Summary: Race condition in using compatibility flags (turns on cascade on detach)  (was: Race condition in using compatibility flags)

> Race condition in using compatibility flags (turns on cascade on detach)
> ------------------------------------------------------------------------
>
>                 Key: OPENJPA-2792
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2792
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 2.4.2
>            Reporter: Pawel Veselov
>            Priority: Major
>
> Compatibility object is used in a lot of placed to determine behavior of the implementation.
> However, compatibility values are set during execution, without regard for other execution threads.
> Looking at {{OpenJPAConfigurationImpl.getCompatibilityInstance()}} once can see that a singleton is used.
> However, broker implementation does this: 
> {code:java}
>         boolean origCascade = _compat.getCascadeWithDetach();
>         _compat.setCascadeWithDetach(true);        
>         try {
>             new DetachManager(this, true, call)
>                 .detachAll(new ManagedObjectCollection(states));
>         } 
>         finally {
>             _compat.setCascadeWithDetach(origCascade);
>         }
> {code}
> This is:
> # turning cascade behavior for other brokers to detach on cascade
> # eventually leads to stuck "true" state, if a broker picks up the compatibility value when another broker has set it temporarily to true.
> Creating of the compatibility object is somewhat complicated, because it can come from compatibility plugin and/or from specification instance. As a brute force solution, I'll just return {{compatibility.clone()}} from {{OpenJPAConfigurationImpl.getCompatibilityInstance()}}, it should take care of this, but there is probably a deeper issue here, especially if there is code paths that expect the compatibility object to be an actual singleton.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)