Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <28267409.post@talk.nabble.com>
Date: Fri, 16 Apr 2010 07:13:20 -0700 (PDT)
From: dnn <Daniel.Nawrocki@ngc.com>
To: users@camel.apache.org
Subject: Re: onException handling
In-Reply-To: <s2h5380c69c1004150240hdb75231n7a9c99e159b9a816@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
References: <28183226.post@talk.nabble.com>
 <z2x5380c69c1004082101s3a22bea1t3631ca930911be32@mail.gmail.com>
 <28191045.post@talk.nabble.com>
 <h2r5380c69c1004090851g9ffffed3had7986f8a685f22d@mail.gmail.com>
 <28196117.post@talk.nabble.com>
 <j2y5380c69c1004100151jce2a50f0r2feab13cc66a4b56@mail.gmail.com>
 <28245275.post@talk.nabble.com>
 <s2h5380c69c1004150240hdb75231n7a9c99e159b9a816@mail.gmail.com>


After a lot more digging, I've found what's really going on.  I'm using
Spring 2.5.6, Camel 2.2.0, ActiveMQ 5.3.1, Hibernate 3.4.0.GA, and Bitronix
1.3.3.  The latest problem I was having (commit() call fails) was because
Hibernate flushes itself to the DB as a pre-commit synchronization listener=
.=20
If I manually called em.flush() the PK violation would be thrown in my
application code and the Camel onException handlers would perform as
expected.  However, I decided that would not be a good way to go forward
(what if the commit failed for some other reason?) and was left still
searching for a solution.

Since almost all of my routes start with a JMS queue, I decided to actually
use the XA functionality in the software I'm using and let any exception
cause a rollback all the way to ActiveMQ.  After a certain number of
rollbacks, ActiveMQ will move the message to a DLQ.  I've added a route tha=
t
reads from the DLQ and does more or less the exact same actions my previous
onException error handler did, but surrounded with a try/catch to prevent
any errors in the DLQ route from causing an infinite loop.  This seems more
like an "enterprise" solution, and I probably should have used it from the
beginning.

Thanks for all your help Claus!


Claus Ibsen-2 wrote:
>=20
> On Wed, Apr 14, 2010 at 6:51 PM, dnn <Daniel.Nawrocki@ngc.com> wrote:
>>
>> This one just won't die :)
>>
>> I've got the same issue, but caused in a slightly different way. =C2=A0T=
he
>> problem is when the DB commit fails (in my case, a unique constraint
>> violation to an Oracle DB), the commit happens outside of the
>> TransactionErrorHandler.super.process(exchange) block, and won't trigger
>> the
>> global onException handlers.
>>
>=20
> That is painful, the Oracle JDBC drivers is really bad.
> You can try with XA to have both JMS + JDBC in the same orchestrated TM.
>=20
>> I've tried to create a unit test to show the issue, but I cannot figure
>> out
>> how to make HSQL throw an exception at commit time. =C2=A0If anyone has =
any
>> tips
>> I'd be happy to create a unit test.
>>
>=20
> Maybe some mock frameworks can do this.
>=20
>=20

--=20
View this message in context: http://old.nabble.com/onException-handling-tp=
28183226p28267409.html
Sent from the Camel - Users mailing list archive at Nabble.com.