[jira] [Created] (OPENJPA-2792) Race condition in using compatibility flags

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

Pawel Veselov created OPENJPA-2792:
--------------------------------------

             Summary: Race condition in using compatibility flags
                 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


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