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

Pawel Veselov commented on OPENJPA-2792:
----------------------------------------

This should work: 
https://github.com/veselov/openjpa/commit/d686814de46bbbb896c99b57c4676ce18272e6eb

> 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