If you don't need an aggregator then you are good to go with SJMS for batch consumers. It is only in the case of an aggregator that there can be an issue where the transaction can close before the aggregator completes.
Let me know if you need anything else. Thanks, Scott ES On Fri, Jan 24, 2014 at 1:37 PM, bacar <ba...@acar.org.uk> wrote: > So, does that mean there is no solution for consuming multiple JMS > messages in a single transaction? Such that transactionality is correctly > respected, ie if something goes wrong with the Nth such message the whole > batch is rolled back. > > > Ideally without the need to use a transactional aggregator to it into a > persistent store. I don't have much interest in configuring a local storage > DB, just want to process the batch of messages and then move on (or roll > back). > -- > Sent from Mailbox for iPhone > > On Fri, Jan 24, 2014 at 3:38 PM, sully6768 [via Camel] > <ml-node+s465427n5746450...@n5.nabble.com> wrote: > > > Hi RK, > > SJMS batch transaction consumes messages individually and does not use or > > produce a List. If you wanted that result you would need to couple the > > SJMS transacted consumer with an aggregator. > > That said, there is a bug in this pattern where a race condition is > > introduced given the batch transaction can close before the aggregator > > completes. I am still working on this issue but hope to have a proper > > solution soon. > > The BatchMessage class is for the producer endpoint given you need to be > > able to able to track the messages as a whole if there is a failure with > > the producer. > > Thanks, > > Scott ES > > On Thu, Jan 16, 2014 at 4:01 PM, <ravi.p...@barclays.com> wrote: > >> Hi, > >> > >> If I understand correctly, it looks like sjms is not to read multiple > >> messages but read a single BatchMessage which is an ArrayList of > messages. > >> > >> Do we have any solution to consume multiple (chunk) JMS messages in a > >> single transaction? > >> > >> Regards > >> RK > >> > >> > >> -----Original Message----- > >> From: bengt.rode...@gmail.com [mailto:bengt.rode...@gmail.com] On > Behalf > >> Of Bengt Rodehav > >> Sent: 26 September 2013 15:01 > >> To: users@camel.apache.org > >> Subject: Re: Consuming multiple JMS messages in one single transaction > >> > >> What about using the "sjms" component instead of the "jms" component. > The > >> documentation says it supports "Transacted Batch Consumers & > Producers". I > >> haven't used this feature myself but I have just started to use the sjms > >> component since I prefer not using Spring. > >> > >> /Bengt > >> > >> > >> 2013/9/24 bacar <ba...@acar.org.uk> > >> > >> > Hi, > >> > I need to do something very similar to this request from April 2012, > ie > >> > consume multiple JMS messages in a single transaction. Is the advice > >> still > >> > current? > >> > > >> > Does the same also apply for the opposite, ie consuming a single > message > >> in > >> > a transaction, and then writing multiple output messages in one > >> > transaction? > >> > > >> > I guess it would be possible to write our own JmsComponent alternative > >> that > >> > supports such functionality and allows us to continue using camel, > but I > >> > imagine that without dedicated support from Spring, it might be quite > a > >> lot > >> > of effort. > >> > > >> > > >> > > >> > -- > >> > View this message in context: > >> > > >> > http://camel.465427.n5.nabble.com/Consuming-multiple-JMS-messages-in-one-single-transaction-tp5640489p5740169.html > >> > Sent from the Camel - Users mailing list archive at Nabble.com. > >> > > >> _______________________________________________ > >> > >> This message is for information purposes only, it is not a > recommendation, > >> advice, offer or solicitation to buy or sell a product or service nor an > >> official confirmation of any transaction. It is directed at persons who > are > >> professionals and is not intended for retail customer use. Intended for > >> recipient only. This message is subject to the terms at: > >> www.barclays.com/emaildisclaimer. > >> > >> For important disclosures, please see: > >> www.barclays.com/salesandtradingdisclaimer regarding market commentary > >> from Barclays Sales and/or Trading, who are active market participants; > and > >> in respect of Barclays Research, including disclosures relating to > specific > >> issuers, please see http://publicresearch.barclays.com. > >> > >> _______________________________________________ > >> > > -- > > -- > > Scott England-Sullivan > > Apache Camel Committer > > Principal Consultant / Sr. Architect | Red Hat, Inc. > > FuseSource is now part of Red Hat > > Web: fusesource.com <http://www.fusesource.com> | > > redhat.com<http://www.redhat.com> > > Blog: sully6768.blogspot.com > > Twitter: sully6768 > > ----- > > -- > > Scott England-Sullivan > > ---------------------------------- > > FuseSource > > Web: http://www.fusesource.com > > Blog: http://sully6768.blogspot.com > > Twitter: sully6768 > > _______________________________________________ > > If you reply to this email, your message will be added to the discussion > below: > > > http://camel.465427.n5.nabble.com/Consuming-multiple-JMS-messages-in-one-single-transaction-tp5640489p5746450.html > > To unsubscribe from Consuming multiple JMS messages in one single > transaction, visit > http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5640489&code=YmFyaXNAYWNhci5vcmcudWt8NTY0MDQ4OXw5NDAyNTMyMjA= > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Consuming-multiple-JMS-messages-in-one-single-transaction-tp5640489p5746460.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- -- Scott England-Sullivan Apache Camel Committer Principal Consultant / Sr. Architect | Red Hat, Inc. FuseSource is now part of Red Hat Web: fusesource.com <http://www.fusesource.com> | redhat.com<http://www.redhat.com> Blog: sully6768.blogspot.com Twitter: sully6768
