Hi, I did a quick search through the open issues and there are several reported problems with cascading. I don't know which one fits your scenario the best. It would help me (at least) if I could see the test case you mentioned.
I'd recommend either opening a new JIRA and attaching your testcase to it, or posting the testcase to something like pastebin <http://pastebin.com/>. -mike On Wed, Apr 13, 2011 at 7:59 AM, Henno Vermeulen <[email protected]>wrote: > Even though the merge succeeds, there is one big issue with removing the > cascade from the bidirectional relation namely I get that > > event != event.activities.get(0).event > > Could this mean that event is unnecessarily fetched and extra unnecessary > SQL gets executed (I've seen issues on this)? > > -----Oorspronkelijk bericht----- > Van: Henno Vermeulen [mailto:[email protected]] > Verzonden: woensdag 13 april 2011 14:40 > Aan: '[email protected]' > Onderwerp: RE: two issues when not using a DetachedStateField > > Issue 2 also does not occury when Activity to Event is not set to cascade. > The issue also doesn't occur when StringI18N is removed and the object > graph is only three entities deep. So it is quite a complicated combination > of factors: no detached state field, four entities and a cascade from > Activity to Event... > > -----Oorspronkelijk bericht----- > Van: Henno Vermeulen [mailto:[email protected]] > Verzonden: woensdag 13 april 2011 14:30 > Aan: '[email protected]' > Onderwerp: two issues when not using a DetachedStateField > > We use OpenJPA 2.1.0 with build time enhancement. We have a client/server > situation so we always detach + serialize entities on commit using fetch > groups: > > <property name="openjpa.DetachState" > value="fetch-groups(DetachedStateField=false)" /> > <property name="openjpa.AutoDetach" value="commit" / > > We currently don't use a DetachedStateField or DetachedStateManager because > everything worked fine without them until now. > > I found two issues that don't occur when I use DetachedStateField=true. > (According to the user guide OpenJPA should function just as well without > one except that it may be less efficient. "OpenJPA can take advantage of a > detached state field to make the attach process more efficient. This field > is added by the enhancer and is not visible to your application.") > > > Issue 1: > When I add a new entity to a List of a detached (but not Serialized) entity > and then merge, OpenJPA throws: > > org.apache.openjpa.persistence.InvalidStateException: The context has been > closed. The stack trace at which the context was closed is held in the > embedded exception. > FailedObject: java.lang.IllegalStateException > at > org.apache.openjpa.kernel.BrokerImpl.assertOpen(BrokerImpl.java:4615) > ....... > > We don't experience this as a problem because we always Serialize an entity > before adjusting it!!! > > > Issue 2: > We have an object graph of four entities with autogenerated Id columns: > > Event (OneToMany bidirectional) Activity (OneToMany) ProductOrderLine > (OneToOne) StringI18N > > All relations are FetchType.EAGER and Cascade.ALL. > > When I add a new Activity (with one new ProductOrderLine with one new > StringI18N) to an existing Event and then merge the Event, OpenJPA tries to > insert a null value into the StringI18N Id column. This seems to be only > detected on transaction commit. > > This problem does not occur when: > > - I make the Event - Activity relation unidirectional, i.e. > Activity does not know it's parent Event. > > - The Event is new as well. > > - (workaround) I first add the new Activity to the Event but with > no ProductOrderLines, then merge the Event, then add the ProductOrderLine to > the Activity in the and merge the Event again. > > Are these known issues? What is the best way for me to go? Should I do my > workaround or should I try to use a detached state field? > Shall I report this to JIRA? I have a test case which shows these issues. > > > Regards, > > Henno Vermeulen > Huize Molenaar > >
