You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by James Carman <ja...@carmanconsulting.com> on 2012/11/09 15:30:53 UTC
Exception handling with JPA and integrity constraints
I have created a little sandbox project to exhibit the behavior I am seeing:
https://github.com/jwcarman/camel-transaction
Right now, I only have two test cases in there and the only difference
between the two is that I'm using this code for the passing one:
https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistWithFlush.java
and I'm using this code for the failing one:
https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistNoFlush.java
The difference is whether or not I use the flush() call or not on my
EntityManager. If I do, everything works fine, since the exceptions
I'm causing (null value constraint and length constraint violations)
are thrown immediately during route processing. If I do not, then the
exception isn't thrown until commit() is called on the
PlatformTransactionManager. Is this expected behavior?
Re: Exception handling with JPA and integrity constraints
Posted by James Carman <ja...@carmanconsulting.com>.
Okay, so what do you suggest? There are two transaction managers you
can tweak here. And, you want the database updates to rollback if the
route fails.
On Fri, Nov 9, 2012 at 5:59 PM, Christian Müller
<ch...@gmail.com> wrote:
> Yes definitely. Using the JpaTransactionManager for the JMS route is wrong.
>
> Best,
> Christian
>
> On Fri, Nov 9, 2012 at 4:29 PM, James Carman <ja...@carmanconsulting.com>wrote:
>
>> We're actually using Camel 2.9.x, since we're on Fuse Enterprise ESB
>> 7.0.1, so I don't think the bridging is available on that version,
>> correct?
>>
>> Also, if I change things up a bit (added a test case to github) and
>> use the JmsTransactionManager for my JmsComponent and the
>> JpaTransactionManager on the route itself, then it behaves as
>> expected. Is this the way we should set it up?
>>
>> On Fri, Nov 9, 2012 at 9:58 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> > You can possible bridge the error handler on the jpa consumer
>> >
>> http://camel.apache.org/why-does-my-file-consumer-not-pick-up-the-file-and-how-do-i-let-the-file-consumer-use-the-camel-error-handler.html
>> >
>> > Then it will trigger a new exchange into the Camel error handler with
>> > the caused exception,
>> > from within the JPA consumer when it tries to flush/commit.
>> >
>> >
>> > On Fri, Nov 9, 2012 at 3:52 PM, James Carman <ja...@carmanconsulting.com>
>> wrote:
>> >> I wasn't talking about whether the JPA stuff was expected. I know
>> >> that's how it's supposed to work. I was talking about the camel side
>> >> of things. Is this just what I'm going to have to do, put flush()
>> >> calls in all my code so that my error handling will kick in? Is that
>> >> what other folks do? Am I even setting up my transaction handling
>> >> stuff correctly (my JMS component uses the JpaTransactionManager and
>> >> so does my route)?
>> >>
>> >> On Fri, Nov 9, 2012 at 9:48 AM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>> >>> On Fri, Nov 9, 2012 at 3:30 PM, James Carman <
>> james@carmanconsulting.com> wrote:
>> >>>> I have created a little sandbox project to exhibit the behavior I am
>> seeing:
>> >>>>
>> >>>> https://github.com/jwcarman/camel-transaction
>> >>>>
>> >>>> Right now, I only have two test cases in there and the only difference
>> >>>> between the two is that I'm using this code for the passing one:
>> >>>>
>> >>>>
>> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistWithFlush.java
>> >>>>
>> >>>> and I'm using this code for the failing one:
>> >>>>
>> >>>>
>> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistNoFlush.java
>> >>>>
>> >>>> The difference is whether or not I use the flush() call or not on my
>> >>>> EntityManager. If I do, everything works fine, since the exceptions
>> >>>> I'm causing (null value constraint and length constraint violations)
>> >>>> are thrown immediately during route processing. If I do not, then the
>> >>>> exception isn't thrown until commit() is called on the
>> >>>> PlatformTransactionManager. Is this expected behavior?
>> >>>
>> >>> I would assume so. As to my knowledge the entity manager controls the
>> >>> database, and therefore may defer writing until an explicit flush is
>> >>> called / or a TX is committed. So if you try to set invalid data, it
>> >>> may not validate this until a write. Though maybe there is some way
>> >>> for it to validate this, in case there is some constrainsts on the
>> >>> Entity class it would know about. Maybe there is something with Bean
>> >>> Validation Spec you can do?
>> >>>
>> >>> I suggest to read about JPA spec and the javadoc of the JPA API /
>> >>> vendor you use.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Claus Ibsen
>> >>> -----------------
>> >>> Red Hat, Inc.
>> >>> FuseSource is now part of Red Hat
>> >>> Email: cibsen@redhat.com
>> >>> Web: http://fusesource.com
>> >>> Twitter: davsclaus
>> >>> Blog: http://davsclaus.com
>> >>> Author of Camel in Action: http://www.manning.com/ibsen
>> >
>> >
>> >
>> > --
>> > Claus Ibsen
>> > -----------------
>> > Red Hat, Inc.
>> > FuseSource is now part of Red Hat
>> > Email: cibsen@redhat.com
>> > Web: http://fusesource.com
>> > Twitter: davsclaus
>> > Blog: http://davsclaus.com
>> > Author of Camel in Action: http://www.manning.com/ibsen
>>
>
>
>
> --
Re: Exception handling with JPA and integrity constraints
Posted by Christian Müller <ch...@gmail.com>.
Yes definitely. Using the JpaTransactionManager for the JMS route is wrong.
Best,
Christian
On Fri, Nov 9, 2012 at 4:29 PM, James Carman <ja...@carmanconsulting.com>wrote:
> We're actually using Camel 2.9.x, since we're on Fuse Enterprise ESB
> 7.0.1, so I don't think the bridging is available on that version,
> correct?
>
> Also, if I change things up a bit (added a test case to github) and
> use the JmsTransactionManager for my JmsComponent and the
> JpaTransactionManager on the route itself, then it behaves as
> expected. Is this the way we should set it up?
>
> On Fri, Nov 9, 2012 at 9:58 AM, Claus Ibsen <cl...@gmail.com> wrote:
> > You can possible bridge the error handler on the jpa consumer
> >
> http://camel.apache.org/why-does-my-file-consumer-not-pick-up-the-file-and-how-do-i-let-the-file-consumer-use-the-camel-error-handler.html
> >
> > Then it will trigger a new exchange into the Camel error handler with
> > the caused exception,
> > from within the JPA consumer when it tries to flush/commit.
> >
> >
> > On Fri, Nov 9, 2012 at 3:52 PM, James Carman <ja...@carmanconsulting.com>
> wrote:
> >> I wasn't talking about whether the JPA stuff was expected. I know
> >> that's how it's supposed to work. I was talking about the camel side
> >> of things. Is this just what I'm going to have to do, put flush()
> >> calls in all my code so that my error handling will kick in? Is that
> >> what other folks do? Am I even setting up my transaction handling
> >> stuff correctly (my JMS component uses the JpaTransactionManager and
> >> so does my route)?
> >>
> >> On Fri, Nov 9, 2012 at 9:48 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >>> On Fri, Nov 9, 2012 at 3:30 PM, James Carman <
> james@carmanconsulting.com> wrote:
> >>>> I have created a little sandbox project to exhibit the behavior I am
> seeing:
> >>>>
> >>>> https://github.com/jwcarman/camel-transaction
> >>>>
> >>>> Right now, I only have two test cases in there and the only difference
> >>>> between the two is that I'm using this code for the passing one:
> >>>>
> >>>>
> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistWithFlush.java
> >>>>
> >>>> and I'm using this code for the failing one:
> >>>>
> >>>>
> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistNoFlush.java
> >>>>
> >>>> The difference is whether or not I use the flush() call or not on my
> >>>> EntityManager. If I do, everything works fine, since the exceptions
> >>>> I'm causing (null value constraint and length constraint violations)
> >>>> are thrown immediately during route processing. If I do not, then the
> >>>> exception isn't thrown until commit() is called on the
> >>>> PlatformTransactionManager. Is this expected behavior?
> >>>
> >>> I would assume so. As to my knowledge the entity manager controls the
> >>> database, and therefore may defer writing until an explicit flush is
> >>> called / or a TX is committed. So if you try to set invalid data, it
> >>> may not validate this until a write. Though maybe there is some way
> >>> for it to validate this, in case there is some constrainsts on the
> >>> Entity class it would know about. Maybe there is something with Bean
> >>> Validation Spec you can do?
> >>>
> >>> I suggest to read about JPA spec and the javadoc of the JPA API /
> >>> vendor you use.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Claus Ibsen
> >>> -----------------
> >>> Red Hat, Inc.
> >>> FuseSource is now part of Red Hat
> >>> Email: cibsen@redhat.com
> >>> Web: http://fusesource.com
> >>> Twitter: davsclaus
> >>> Blog: http://davsclaus.com
> >>> Author of Camel in Action: http://www.manning.com/ibsen
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > Red Hat, Inc.
> > FuseSource is now part of Red Hat
> > Email: cibsen@redhat.com
> > Web: http://fusesource.com
> > Twitter: davsclaus
> > Blog: http://davsclaus.com
> > Author of Camel in Action: http://www.manning.com/ibsen
>
--
Re: Exception handling with JPA and integrity constraints
Posted by James Carman <ja...@carmanconsulting.com>.
We're actually using Camel 2.9.x, since we're on Fuse Enterprise ESB
7.0.1, so I don't think the bridging is available on that version,
correct?
Also, if I change things up a bit (added a test case to github) and
use the JmsTransactionManager for my JmsComponent and the
JpaTransactionManager on the route itself, then it behaves as
expected. Is this the way we should set it up?
On Fri, Nov 9, 2012 at 9:58 AM, Claus Ibsen <cl...@gmail.com> wrote:
> You can possible bridge the error handler on the jpa consumer
> http://camel.apache.org/why-does-my-file-consumer-not-pick-up-the-file-and-how-do-i-let-the-file-consumer-use-the-camel-error-handler.html
>
> Then it will trigger a new exchange into the Camel error handler with
> the caused exception,
> from within the JPA consumer when it tries to flush/commit.
>
>
> On Fri, Nov 9, 2012 at 3:52 PM, James Carman <ja...@carmanconsulting.com> wrote:
>> I wasn't talking about whether the JPA stuff was expected. I know
>> that's how it's supposed to work. I was talking about the camel side
>> of things. Is this just what I'm going to have to do, put flush()
>> calls in all my code so that my error handling will kick in? Is that
>> what other folks do? Am I even setting up my transaction handling
>> stuff correctly (my JMS component uses the JpaTransactionManager and
>> so does my route)?
>>
>> On Fri, Nov 9, 2012 at 9:48 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>> On Fri, Nov 9, 2012 at 3:30 PM, James Carman <ja...@carmanconsulting.com> wrote:
>>>> I have created a little sandbox project to exhibit the behavior I am seeing:
>>>>
>>>> https://github.com/jwcarman/camel-transaction
>>>>
>>>> Right now, I only have two test cases in there and the only difference
>>>> between the two is that I'm using this code for the passing one:
>>>>
>>>> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistWithFlush.java
>>>>
>>>> and I'm using this code for the failing one:
>>>>
>>>> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistNoFlush.java
>>>>
>>>> The difference is whether or not I use the flush() call or not on my
>>>> EntityManager. If I do, everything works fine, since the exceptions
>>>> I'm causing (null value constraint and length constraint violations)
>>>> are thrown immediately during route processing. If I do not, then the
>>>> exception isn't thrown until commit() is called on the
>>>> PlatformTransactionManager. Is this expected behavior?
>>>
>>> I would assume so. As to my knowledge the entity manager controls the
>>> database, and therefore may defer writing until an explicit flush is
>>> called / or a TX is committed. So if you try to set invalid data, it
>>> may not validate this until a write. Though maybe there is some way
>>> for it to validate this, in case there is some constrainsts on the
>>> Entity class it would know about. Maybe there is something with Bean
>>> Validation Spec you can do?
>>>
>>> I suggest to read about JPA spec and the javadoc of the JPA API /
>>> vendor you use.
>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> Red Hat, Inc.
>>> FuseSource is now part of Red Hat
>>> Email: cibsen@redhat.com
>>> Web: http://fusesource.com
>>> Twitter: davsclaus
>>> Blog: http://davsclaus.com
>>> Author of Camel in Action: http://www.manning.com/ibsen
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
Re: Exception handling with JPA and integrity constraints
Posted by Claus Ibsen <cl...@gmail.com>.
You can possible bridge the error handler on the jpa consumer
http://camel.apache.org/why-does-my-file-consumer-not-pick-up-the-file-and-how-do-i-let-the-file-consumer-use-the-camel-error-handler.html
Then it will trigger a new exchange into the Camel error handler with
the caused exception,
from within the JPA consumer when it tries to flush/commit.
On Fri, Nov 9, 2012 at 3:52 PM, James Carman <ja...@carmanconsulting.com> wrote:
> I wasn't talking about whether the JPA stuff was expected. I know
> that's how it's supposed to work. I was talking about the camel side
> of things. Is this just what I'm going to have to do, put flush()
> calls in all my code so that my error handling will kick in? Is that
> what other folks do? Am I even setting up my transaction handling
> stuff correctly (my JMS component uses the JpaTransactionManager and
> so does my route)?
>
> On Fri, Nov 9, 2012 at 9:48 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> On Fri, Nov 9, 2012 at 3:30 PM, James Carman <ja...@carmanconsulting.com> wrote:
>>> I have created a little sandbox project to exhibit the behavior I am seeing:
>>>
>>> https://github.com/jwcarman/camel-transaction
>>>
>>> Right now, I only have two test cases in there and the only difference
>>> between the two is that I'm using this code for the passing one:
>>>
>>> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistWithFlush.java
>>>
>>> and I'm using this code for the failing one:
>>>
>>> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistNoFlush.java
>>>
>>> The difference is whether or not I use the flush() call or not on my
>>> EntityManager. If I do, everything works fine, since the exceptions
>>> I'm causing (null value constraint and length constraint violations)
>>> are thrown immediately during route processing. If I do not, then the
>>> exception isn't thrown until commit() is called on the
>>> PlatformTransactionManager. Is this expected behavior?
>>
>> I would assume so. As to my knowledge the entity manager controls the
>> database, and therefore may defer writing until an explicit flush is
>> called / or a TX is committed. So if you try to set invalid data, it
>> may not validate this until a write. Though maybe there is some way
>> for it to validate this, in case there is some constrainsts on the
>> Entity class it would know about. Maybe there is something with Bean
>> Validation Spec you can do?
>>
>> I suggest to read about JPA spec and the javadoc of the JPA API /
>> vendor you use.
>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Email: cibsen@redhat.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Exception handling with JPA and integrity constraints
Posted by James Carman <ja...@carmanconsulting.com>.
I wasn't talking about whether the JPA stuff was expected. I know
that's how it's supposed to work. I was talking about the camel side
of things. Is this just what I'm going to have to do, put flush()
calls in all my code so that my error handling will kick in? Is that
what other folks do? Am I even setting up my transaction handling
stuff correctly (my JMS component uses the JpaTransactionManager and
so does my route)?
On Fri, Nov 9, 2012 at 9:48 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Fri, Nov 9, 2012 at 3:30 PM, James Carman <ja...@carmanconsulting.com> wrote:
>> I have created a little sandbox project to exhibit the behavior I am seeing:
>>
>> https://github.com/jwcarman/camel-transaction
>>
>> Right now, I only have two test cases in there and the only difference
>> between the two is that I'm using this code for the passing one:
>>
>> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistWithFlush.java
>>
>> and I'm using this code for the failing one:
>>
>> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistNoFlush.java
>>
>> The difference is whether or not I use the flush() call or not on my
>> EntityManager. If I do, everything works fine, since the exceptions
>> I'm causing (null value constraint and length constraint violations)
>> are thrown immediately during route processing. If I do not, then the
>> exception isn't thrown until commit() is called on the
>> PlatformTransactionManager. Is this expected behavior?
>
> I would assume so. As to my knowledge the entity manager controls the
> database, and therefore may defer writing until an explicit flush is
> called / or a TX is committed. So if you try to set invalid data, it
> may not validate this until a write. Though maybe there is some way
> for it to validate this, in case there is some constrainsts on the
> Entity class it would know about. Maybe there is something with Bean
> Validation Spec you can do?
>
> I suggest to read about JPA spec and the javadoc of the JPA API /
> vendor you use.
>
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
Re: Exception handling with JPA and integrity constraints
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Nov 9, 2012 at 3:30 PM, James Carman <ja...@carmanconsulting.com> wrote:
> I have created a little sandbox project to exhibit the behavior I am seeing:
>
> https://github.com/jwcarman/camel-transaction
>
> Right now, I only have two test cases in there and the only difference
> between the two is that I'm using this code for the passing one:
>
> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistWithFlush.java
>
> and I'm using this code for the failing one:
>
> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistNoFlush.java
>
> The difference is whether or not I use the flush() call or not on my
> EntityManager. If I do, everything works fine, since the exceptions
> I'm causing (null value constraint and length constraint violations)
> are thrown immediately during route processing. If I do not, then the
> exception isn't thrown until commit() is called on the
> PlatformTransactionManager. Is this expected behavior?
I would assume so. As to my knowledge the entity manager controls the
database, and therefore may defer writing until an explicit flush is
called / or a TX is committed. So if you try to set invalid data, it
may not validate this until a write. Though maybe there is some way
for it to validate this, in case there is some constrainsts on the
Entity class it would know about. Maybe there is something with Bean
Validation Spec you can do?
I suggest to read about JPA spec and the javadoc of the JPA API /
vendor you use.
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen