[
https://issues.apache.org/jira/browse/OPENJPA-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16884012#comment-16884012
]
Pawel Veselov commented on OPENJPA-2792:
----------------------------------------
After some thinking, cloning the compatibility object is not helpful.
First, the way that the specs set up their configuration is complicated, they
obtain the config object, then edit it, rather then having the configurator ask
the spec to produce it.
Second, if compat is cloned, then the somebody may use a cloned option, when it
should be changed.
I hope there isn't more code in there that changes compat object like that.
For now, I added both "cascadeWithDetach" and "copyOnDetach" as properties of
the broker itself, loaded at initialization time. Then DetachManager (the only
consumer of those anyway), uses broker properties. Broker impl and entity
manager temporary set broker properties when they need this behavior enforced.
I hope that the intent was that the option stays within one broker, and entity
manager, and there is a 1-1 correlation between the two
> 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)
