Yes definitely. Using the JpaTransactionManager for the JMS route is wrong.
Best, Christian On Fri, Nov 9, 2012 at 4:29 PM, James Carman <[email protected]>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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > wrote: > >>> On Fri, Nov 9, 2012 at 3:30 PM, James Carman < > [email protected]> 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: [email protected] > >>> 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: [email protected] > > Web: http://fusesource.com > > Twitter: davsclaus > > Blog: http://davsclaus.com > > Author of Camel in Action: http://www.manning.com/ibsen > --
