Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Reply-To: <cnd@cndavies.com>
From: "C N Davies" <cnd@cndavies.com>
To: <users@openjpa.apache.org>
References: <1912454679.671274933468969.JavaMail.root@zimbra>
 <1359306573.691274935245855.JavaMail.root@zimbra>
In-Reply-To: <1359306573.691274935245855.JavaMail.root@zimbra>
Subject: RE: openjpa-1.2.1 partial commit problem
Date: Thu, 27 May 2010 16:25:14 +1000
Organization: C N Davies Pty Ltd
Message-ID: <05c101cafd65$60c073f0$22415bd0$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Acr9XpkN8kMsQ669Qm+1qktrGIzzywABeZvw
Content-Language: en-au

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:trent@trentonadams.ca]=20
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=20
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 =3D 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.