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)
