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

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 2.4.2
• Component/s: kernel
• Assignee: Unassigned
• Reporter: Pawel Veselov
• Created: 12/Jul/19 13:34
• Updated: 22/Jul/19 22:47

Description

Compatibility object is used in a lot of places 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:

        boolean origCascade = _compat.getCascadeWithDetach();
        _compat.setCascadeWithDetach(true);        
        try {
            new DetachManager(this, true, call)
                .detachAll(new ManagedObjectCollection(states));
        } 
        finally {
            _compat.setCascadeWithDetach(origCascade);
        }

This is:

1. turning cascade behavior for other brokers to detach on cascade
2. 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.