[
https://issues.apache.org/jira/browse/OPENJPA-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pawel Veselov updated OPENJPA-2792:
-----------------------------------
Description:
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.
was:
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.
> 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
> 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)
