On Tue, Nov 15, 2011 at 4:52 PM, Preben.Asmussen <p...@dr.dk> wrote: > @Claus > > +1 This would be really helpfull. > > In addition to the problem you laid out I can tell that consuming 100 rows > -> processing the 70 building a xml payload -> put in on a jms queue and > then on the 71 have an error that rolles everything back ultimately can fill > up the redolog off the db and bring it to it's knees. > Because of this we only consume one record at the time + have a onException > handler with backoff. >
Yeah I would suggest to pickup only 1 row at the time if you want to enforce transactional integrity, when multiple TX resources is involved such as JPA + JMS. Or at least limit the number of messages to pickup, to a reasonable size, to avoid the number of participating messages in the TX gets too big, as well the memory consumption needed would be bigger etc. Of course if speed is important, then you may be able to find a reasonable batch size. > preben > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Misleading-jmx-statistics-on-jpa-component-tp4960503p4994706.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
