You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by C N Davies <cn...@cndavies.com> on 2010/04/04 18:12:21 UTC
Unmanaged Object Problems
Hi,
This is a problem that continues to haunt me intermittently since I first
started using OpenJPA and cannot understand why it comes up from time to
time for no apparent reason.
I have an Entity like this:
@Entity
public class DataLoad {
..
@ManyToOne(cascade={CascadeType.REFRESH})
private LoadConfig loadConfig;
...
}
@Entity
public class LoadConfig {
..
private String name;
private Date createDate;
...
}
If I create a new DataLoad entity and use em.save(dataload) is all works
fine, but if later use em.merge(dataload); since I made some changes to the
entity I get this stack trace:
<openjpa-2.0.0-beta-r422266:903062M nonfatal user error>
org.apache.openjpa.persistence.InvalidStateException: Encountered unmanaged
object in persistent field "com.trm.core.DataLoad.loadConfig" during flush.
However, this field does not allow cascade persist. Set the cascade
attribute for this field to CascadeType.PERSIST or CascadeType.ALL (JPA
annotations) or "persist" or "all" (JPA orm.xml), or enable cascade-persist
globally, or manually persist the related field value prior to flushing. You
cannot flush unmanaged objects or graphs that have persistent associations
to unmanaged objects.
FailedObject:
org.apache.openjpa.enhance.com$trm$core$LoadConfig$pcsubclass-00000126A871C0
E8
at
org.apache.openjpa.kernel.SingleFieldManager.preFlushPC(SingleFieldManager.j
ava:767)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.jav
a:607)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.jav
a:575)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.jav
a:491)
at
org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:29
56)
at org.apache.openjpa.kernel.PNewState.beforeFlush(PNewState.java:40)
at
org.apache.openjpa.kernel.StateManagerImpl.beforeFlush(StateManagerImpl.java
:1048)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2053)
at
org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2013)
at
org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1931)
at
org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.jav
a:81)
at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1455)
at
org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:903)
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.ja
va:551)
I do not want to persist anything in the loadConfig field, I am only using
cascade={CascadeType.REFRESH} so that OpenJPA will create the joins, so why
is OpenJPA complaining that I need to turn on CascadeType.PERSIST etc and
why does it only happen when I use merge?
Using OpenJPA 2.0.0 Beta 2 and also getting the same issue on 1.2.2 as well.
Thanks for any pointers J
Chris
RE: Unmanaged Object Problems
Posted by Simon Droscher <si...@elasticpath.com>.
Chris,
I have seen this kind of error in quite a few cases, usually under load -
what can happen is the entity being refreshed/join is in the middle of being
detached from a previous operation and thus the merge sees the wrong state.
I found that a more immediate detach works wonders, i.e. putting the
following in persistence.xml
<property name="openjpa.AutoDetach" value="close, commit, nontx-read"/>
Simon
crispyoz wrote:
>
> By intermittent I mean that I can basically use the same method for
> linking
> my Entities and quite randomly I suddenly I'll make some new entity
> classes
> and I get these kinds of problems.
>
--
View this message in context: http://n2.nabble.com/Unmanaged-Object-Problems-tp4850707p4861230.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
RE: Unmanaged Object Problems
Posted by C N Davies <cn...@cndavies.com>.
HI Darryl,
By intermittent I mean that I can basically use the same method for linking
my Entities and quite randomly I suddenly I'll make some new entity classes
and I get these kinds of problems. I suspect you may be correct that the
child entity being in a different em, I have never been happy with how I
use the em in my applications, I'll have bit more of a think about it and
see if I can sew what is going on. Thanks for the tip
To be honest the whole cascade type system to me has a gaping hole in it, I
don't understand why there is no CascadeType of "Join" where we are simply
telling the JPA engine that we are only creating a join and no need to
update/refresh the child entity each time the main entity is save/merged.
Regards
Chris
From: Daryl Stultz [mailto:daryl@6degrees.com]
Sent: Monday, 5 April 2010 10:32 PM
To: users@openjpa.apache.org; cnd@cndavies.com
Subject: Re: Unmanaged Object Problems
On Sun, Apr 4, 2010 at 12:12 PM, C N Davies <cn...@cndavies.com> wrote:
This is a problem that continues to haunt me intermittently since I first
started using OpenJPA and cannot understand why it comes up from time to
time for no apparent reason.
Hi Chris, when you say it's "intermittent" do you mean it's not
reproducible? If you recall, I ran into the same crash from time to time. I
was able to reproduce the stack trace with a unit test but was never sure if
my live app was failing for the same reason. My unit test would try to merge
an object that had a reference to an object that was attached to a
*different* em. So the error message says it's unmanaged but it's actually
managed by another em. I found a gaping hole in my em management routine
that was leaving em's open under a certain race condition. It's a plausible
scenario that could bring my app and unit test together. So you might study
your app and see if it's possible the failedObject could be attached to a
different em.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Unmanaged Object Problems
Posted by Rick Curtis <cu...@gmail.com>.
As long as getEmFromFactory(); returns a fresh em (ie:
emf.createEntityManager), that code should be safe. Since both threads will
have different em references, calling em.find(B.class, 123) will also return
two separate instances. More so, EntityManagers aren't supposed to be shared
by threads so this scenario isn't valid if getEmFromFactory() returns the
same instance to two different threads.
--
Thanks,
Rick
On Mon, Apr 5, 2010 at 3:28 PM, Daryl Stultz <da...@6degrees.com> wrote:
> On Mon, Apr 5, 2010 at 4:05 PM, Rick Curtis <cu...@gmail.com> wrote:
>
> > Daryl I'm not entirely sure I follow your last email. My understanding of
> > the problem is that we are trying to merge a detached entity that has a
> > relationship to an entity which is in a different persistence context.
>
>
> I don't think I have a good enough understanding of JPA to explain what I
> mean. Maybe something like this:
>
> em = getEmFromFactory();
> EntityB b = getBFromQuery(em);
> EntityA a = new EntityA();
> a.setB(b);
> Thread.sleep(1000);
> em.persist(a);
>
> If two threads enter this code overlapping by a few millis, could "b" fail
> due to it being managed by the other thread's em? I figure if the problem
> with my code resulted in an em being left open and this error being thrown,
> then there might be a race condition present even after fixing the problem
> in my code, just with a smaller window.
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
Re: Unmanaged Object Problems
Posted by Daryl Stultz <da...@6degrees.com>.
On Mon, Apr 5, 2010 at 4:05 PM, Rick Curtis <cu...@gmail.com> wrote:
> Daryl I'm not entirely sure I follow your last email. My understanding of
> the problem is that we are trying to merge a detached entity that has a
> relationship to an entity which is in a different persistence context.
I don't think I have a good enough understanding of JPA to explain what I
mean. Maybe something like this:
em = getEmFromFactory();
EntityB b = getBFromQuery(em);
EntityA a = new EntityA();
a.setB(b);
Thread.sleep(1000);
em.persist(a);
If two threads enter this code overlapping by a few millis, could "b" fail
due to it being managed by the other thread's em? I figure if the problem
with my code resulted in an em being left open and this error being thrown,
then there might be a race condition present even after fixing the problem
in my code, just with a smaller window.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Unmanaged Object Problems
Posted by Rick Curtis <cu...@gmail.com>.
Daryl I'm not entirely sure I follow your last email. My understanding of
the problem is that we are trying to merge a detached entity that has a
relationship to an entity which is in a different persistence context. I'm
quite certain that OpenJPA doesn't allow you to share entities across
multiple persistence contexts so having two threads sharing the same entity
should be a non issue... unless we were to fix/allow that.
--
Thanks,
Rick
On Mon, Apr 5, 2010 at 2:15 PM, Daryl Stultz <da...@6degrees.com> wrote:
> On Mon, Apr 5, 2010 at 2:45 PM, Rick Curtis <cu...@gmail.com> wrote:
>
> > I believe that OpenJPA should be throwing an exception as
> > pasted below, rather then the one that you are seeing.
> >
>
> I agree that a better message is needed and there was certainly a problem
> with my code. However, I'm wondering if there is still a general race
> condition problem? Suppose 2 threads are slamming in EntityA records, all
> with a reference to a single EntityB record. Would the possibility of this
> exception being triggered be pretty high?
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
Re: Unmanaged Object Problems
Posted by Daryl Stultz <da...@6degrees.com>.
On Mon, Apr 5, 2010 at 2:45 PM, Rick Curtis <cu...@gmail.com> wrote:
> I believe that OpenJPA should be throwing an exception as
> pasted below, rather then the one that you are seeing.
>
I agree that a better message is needed and there was certainly a problem
with my code. However, I'm wondering if there is still a general race
condition problem? Suppose 2 threads are slamming in EntityA records, all
with a reference to a single EntityB record. Would the possibility of this
exception being triggered be pretty high?
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Unmanaged Object Problems
Posted by Rick Curtis <cu...@gmail.com>.
I think Daryl hit it spot on. I was able to reproduce the exception from the
previous email and I believe that OpenJPA should be throwing an exception as
pasted below, rather then the one that you are seeing.
...
Caused by: <openjpa-2.1.0-SNAPSHOT-r422266:930721M nonfatal user error>
org.apache.openjpa.persistence.ArgumentException: The given instance
"cache.Entity-106351" is not managed by this context.
FailedObject: cache.Entity-106351
at
org.apache.openjpa.kernel.BrokerImpl.getStateManagerImpl(BrokerImpl.java:4513)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlushPC(SingleFieldManager.java:767)
...
I'll open a JIRA in the coming days to fix this problem so we throw a more
meaningful message.
--
Thanks,
Rick
On Mon, Apr 5, 2010 at 7:31 AM, Daryl Stultz <da...@6degrees.com> wrote:
> On Sun, Apr 4, 2010 at 12:12 PM, C N Davies <cn...@cndavies.com> wrote:
>
> > This is a problem that continues to haunt me intermittently since I first
> > started using OpenJPA and cannot understand why it comes up from time to
> > time for no apparent reason.
> >
>
> Hi Chris, when you say it's "intermittent" do you mean it's not
> reproducible? If you recall, I ran into the same crash from time to time. I
> was able to reproduce the stack trace with a unit test but was never sure
> if
> my live app was failing for the same reason. My unit test would try to
> merge
> an object that had a reference to an object that was attached to a
> *different* em. So the error message says it's unmanaged but it's actually
> managed by another em. I found a gaping hole in my em management routine
> that was leaving em's open under a certain race condition. It's a plausible
> scenario that could bring my app and unit test together. So you might study
> your app and see if it's possible the failedObject could be attached to a
> different em.
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
Re: Unmanaged Object Problems
Posted by Daryl Stultz <da...@6degrees.com>.
On Sun, Apr 4, 2010 at 12:12 PM, C N Davies <cn...@cndavies.com> wrote:
> This is a problem that continues to haunt me intermittently since I first
> started using OpenJPA and cannot understand why it comes up from time to
> time for no apparent reason.
>
Hi Chris, when you say it's "intermittent" do you mean it's not
reproducible? If you recall, I ran into the same crash from time to time. I
was able to reproduce the stack trace with a unit test but was never sure if
my live app was failing for the same reason. My unit test would try to merge
an object that had a reference to an object that was attached to a
*different* em. So the error message says it's unmanaged but it's actually
managed by another em. I found a gaping hole in my em management routine
that was leaving em's open under a certain race condition. It's a plausible
scenario that could bring my app and unit test together. So you might study
your app and see if it's possible the failedObject could be attached to a
different em.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com