Oh, I definitely want to do that, now that I know about it. Just waiting for a response on my other topic. I'm thinking it's probably related to some sort of annotation that I need to do on my enum, but don't know what.
----- "C N Davies" <[email protected]> wrote: > From: "C N Davies" <[email protected]> > To: [email protected] > Sent: Thursday, May 27, 2010 12:25:14 AM GMT -07:00 US/Canada Mountain > Subject: RE: openjpa-1.2.1 partial commit problem > > Use prepersist / preupate listeners, you can check the content of your > objects inside there. > > Trust me, you would be better to spend your time working out why build > time enhancement blows up one of your objects, as I mentioned before > and Pinaki re-iterated runtime enhancement will often cause issues > that manifest themselves nowhere near the root cause of the issue. I > would not be all surprise if your issue does related to run time > enhancement. I went down the road of relying on run time enhancement > for months so I din't have to worry about setting up ant, I saved time > not having to work on ant but I lost 10 times the time trying to sort > out strange issues that never made any sense but turned out to be the > runtime enhancer. If it was up to me I'd remove it completely > > Chris > > > -----Original Message----- > From: Trenton D. Adams [mailto:[email protected]] > Sent: Thursday, 27 May 2010 2:41 PM > To: openjpa-users > Subject: openjpa-1.2.1 partial commit problem > > Hi Guys, > > I am not yet using the build time enhancer, as it currently blows up > on one of my objects, as noted in another message to the list. So, > it's sticking to runtime subclassing. > > I'm having the oddest problem. I am using EJB3, and have a method > that REQUIRES_NEW for the transaction. It works fine like that, but > as soon as I remove that attribute, to get the default transaction > attribute, my records are only partially committed, literally. > > So, what I'm trying to do, is > 1. put a journal entry in with the message "pre commit entry" in it's > own transaction, to make sure something is entered in, in case > something happens that blows up the rest of the commit process. That > way someone knows why the serial column has a missing journal number. > 2. add some entity objects to the journal entry, as a collection > 3. merge the journal entry again with objects in the collection > > That's fine, but I decided to remove the REQUIRES_NEW, just to see if > my unit tests would fail. I found out really quickly that only one > item of the collection is being persisted to the database. > > I am effectively going like this (pseudo code)... > > --- method with REQUIRES_NEW > entityManager.persist(journalEntry); > entityManager.flush(); // if this flush is removed, it > works without REQUIRES_NEW, but not otherwise. > > --- method that calls method with REQUIRES_NEW > journalEntry = new JournalEntry( > ledgerBroker.getJournalType(), "pre commit entry"); > sessionContext.getBusinessObject( > RIJournalEntryManager.class).persistMethod(journalEntry); > journalEntry.addItem(blah); > journalEntry.addItem(blah); > entityManager.merge(journalEntry); > entityManager.flush(); > > It seems to me that this is a bug in openjpa, but I cannot be certain, > as I'm VERY new to EJB/JPA.
