On Fri, Sep 18, 2009 at 10:51 AM, Daryl Stultz <[email protected]> wrote:
> > On Fri, Sep 18, 2009 at 10:36 AM, C N Davies <[email protected]> wrote: > >> >> Next it gets the persistence context. This is where I have a suspicion the >> issue is occurring >> >> > Can you do me a favor and keep your code such that the object is detached > and causing the failure and tell me how _broker.isDetachedNew() and > _broker.isDetached(obj) evaluate? I realize the second may be tricky if the > first returns false. This is the one thing I can't do since I can't repeat > it. > > After some code sniffing, I've determined that EntityManagerFactoryImpl.createEntityManager(...) is calling broker.setDetachedNew(false) and this is the only place broker.setDetachedNew is called. So _broker.isDetachedNew() should always return false. The default for BrokerImpl._detachedNew is true so either: _broker.isDetached(obj) is not returning true when I think it should. or I'm somehow getting an EM that was not created by EntityManagerFactoryImpl.createEntityManager(...). This seems rather unlikely. So I'm thinking my problem is with _broker.isDetached(obj). I can reproduce the crash by persisting a new object with a field set to a new object. The traceback is the same as my production code except the rendering of the FailedObject is different. My production crash includes the ID of the FailedObject which indicates it is not new. If I set the ID of my new field member to an existing record, the test passes. I guess I need to figure out why _broker.isDetached(obj) thinks my object is completely new. -- Daryl Stultz _____________________________________ 6 Degrees Software and Consulting, Inc. http://www.6degrees.com mailto:[email protected]
