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

Reply via email to