You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by nlif <na...@dbnet.co.il> on 2006/07/19 17:04:36 UTC
Consuming a group of messages in a single transaction
Hi,
I am using ActiveMQ's MessageGroups feature in order to send and receive
several related messages as a single unit-of-work. I am using a transacted
producer, so all messages are sent atomically, but I don't know how to
implement the consumer. The way I see it - the consumer should accumulate
the messages until it has all of them and then construct the aggregate, save
it and only then - acknowledge them.
Just to clarfiy, the problem I am trying to solve is that of the consumer
crashing after acknowleding some, but not all, of the messages in the group.
This will result in loss of messages.
So I started-off with a MessageListener configured with Jencks, for pooling.
The MessageListener should collect all messages in the group, and once it
has all of them - it should acknowledge all of the together. Now, ensuring
all messages are indeed delivered to the same MessageListener is taken care
of by the MessageGroups feature. But since Jencks commits the transaction
when the onMessage() method returns - this prevents me from acknowledging
all messages together.
I know some people throw a RuntimeException in the onMessage() method in
order to make Jencks rollback, but that's awkward to say the least, since it
will cause messages I already have to be redlivered again and again!
Furthermore, if I am not mistaken, although all Jencks' threads share the
same MessageListener instance, each message is (or may be) delivered by a
different session. This means, that even if I did find a way to commit the
transaction myself - it would still not achieve the behavior I need.
Is there any way to consume several messages in a single transaction, while
using an async consumer and Jencks? Or is there another way, and I am simply
approaching the whole thing in the wrong way?
I'd appreciate any tips.
Thanks,
Naaman
--
View this message in context: http://www.nabble.com/Consuming-a-group-of-messages-in-a-single-transaction-tf1966918.html#a5397996
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Consuming a group of messages in a single transaction
Posted by nlif <na...@dbnet.co.il>.
>> I guess I could load and send the file in chunks, using ByteMessages,
>> probably in the same manner the ActiveMQ output stream does it. So I will
>> be
>> using my own streaming solution, instead of an AMQ feature, but will gain
>> the ablility to defer commiting until I have the whole stream.
>
>The reason I've been suggesting splitting the file up is precisely so
>that you can commit/acknowledge the message in chunks - rather than
>deferring until you've got all of the messages. If you must defer
>until you have all of the messages then using BytesMessage or the JMS
>streams will have the same effect - the broker will need to keep them
>all around in RAM until you commit/ack.
Ok, so what you're saying is that deferring message acknowledgement is a bad
strategy anyway, especially if the transactions are long and the files are
big. Ok, that's good advice :-)
So let's say I acknowledge file-chunks and/or other messages (that logically
belong together) one at a time, as I get them. In this case I can use the
ActiveMQ streams and maybe even non-transacted sessions, with auto-ack. But
now, if my consumer crashes while it's in the middle of such a multi-part
transmission, the messages already acknowldeged will be lost, and I can no
longer rely on the broker for redelivering them.
Therefore, maybe I should not use the broker's guaranteed delivery for this
purpose, and instead, imlpement a consumer with persistent/recoverable
cache. Every message that is acknowledged is also persisted on the consumer
side somehow (file system, database). Then, when the consumer verifies it
has all parts of the "package" (e.g. all chunks of the file and all related
messages) - it can grab them from whereever they were persisted, and forward
them together to be processed by the business tier.
BTW - I think you misunderstood my question about the ZIP file: the
intention was not compression, but to be able to pass around several things
together... but maybe it's a bad idea anyway :-)
Naaman
--
View this message in context: http://www.nabble.com/Consuming-a-group-of-messages-in-a-single-transaction-tf1966918.html#a5536994
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Consuming a group of messages in a single transaction
Posted by James Strachan <ja...@gmail.com>.
On 7/28/06, nlif <na...@dbnet.co.il> wrote:
>
> I guess I could load and send the file in chunks, using ByteMessages,
> probably in the same manner the ActiveMQ output stream does it. So I will be
> using my own streaming solution, instead of an AMQ feature, but will gain
> the ablility to defer commiting until I have the whole stream.
The reason I've been suggesting splitting the file up is precisely so
that you can commit/acknowledge the message in chunks - rather than
deferring until you've got all of the messages. If you must defer
until you have all of the messages then using BytesMessage or the JMS
streams will have the same effect - the broker will need to keep them
all around in RAM until you commit/ack.
> BTW, another idea tossed around in our team was to wrap all items in a ZIP
> file, and them send it in a single (albeit huge) ByteMessage. Does this
> sound like a good idea to you? Are you aware of anyone using ZIP files for
> this?
We have compression on messages which you can enable which effectively
turn all messages into zips to compress things down. Though how much
compression are you gonna get on 200Mb?
To enable compression see the useCompression option...
http://incubator.apache.org/activemq/connection-configuration-uri.html
--
James
-------
http://radio.weblogs.com/0112098/
Re: Consuming a group of messages in a single transaction
Posted by nlif <na...@dbnet.co.il>.
I guess I could load and send the file in chunks, using ByteMessages,
probably in the same manner the ActiveMQ output stream does it. So I will be
using my own streaming solution, instead of an AMQ feature, but will gain
the ablility to defer commiting until I have the whole stream. This will
also allow me to mix Files and other message types in the same transaction.
Hmm... is this my way out of this mess? :-)
BTW, another idea tossed around in our team was to wrap all items in a ZIP
file, and them send it in a single (albeit huge) ByteMessage. Does this
sound like a good idea to you? Are you aware of anyone using ZIP files for
this?
Naaman
--
View this message in context: http://www.nabble.com/Consuming-a-group-of-messages-in-a-single-transaction-tf1966918.html#a5535999
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Consuming a group of messages in a single transaction
Posted by James Strachan <ja...@gmail.com>.
Can you not split up the 200Mb file into pieces?
On 7/28/06, nlif <na...@dbnet.co.il> wrote:
>
> Thanks James.
>
> Let me describe a typical use-case: I need to send some kind of a command
> object along with a binary file. I serialize the command object to XML and
> send it as a JMS TextMessage. Now comes the file, which is quite large
> (~200Mb), so I need streaming. The problem is - what happens if the consumer
> got the TextMessage and acknowledged it, and then crashed? The File may
> eventually get there, possibly using a different consumer thread (*) but the
> TextMessage will not be redelivered since it was acknowledged. That's why,
> in my opinion, and please correct me if I'm wrong here, I need a transaction
> to include both the TextMessage and the file.
>
> Naaman
>
> (*) Since we're deployed in a cluster, the TextMessage and the File might
> have ended up in different nodes altogether, but luckily there's ActiveMQ
> MessageGroups :-)
>
> --
> View this message in context: http://www.nabble.com/Consuming-a-group-of-messages-in-a-single-transaction-tf1966918.html#a5535611
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Consuming a group of messages in a single transaction
Posted by nlif <na...@dbnet.co.il>.
Thanks James.
Let me describe a typical use-case: I need to send some kind of a command
object along with a binary file. I serialize the command object to XML and
send it as a JMS TextMessage. Now comes the file, which is quite large
(~200Mb), so I need streaming. The problem is - what happens if the consumer
got the TextMessage and acknowledged it, and then crashed? The File may
eventually get there, possibly using a different consumer thread (*) but the
TextMessage will not be redelivered since it was acknowledged. That's why,
in my opinion, and please correct me if I'm wrong here, I need a transaction
to include both the TextMessage and the file.
Naaman
(*) Since we're deployed in a cluster, the TextMessage and the File might
have ended up in different nodes altogether, but luckily there's ActiveMQ
MessageGroups :-)
--
View this message in context: http://www.nabble.com/Consuming-a-group-of-messages-in-a-single-transaction-tf1966918.html#a5535611
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Consuming a group of messages in a single transaction
Posted by James Strachan <ja...@gmail.com>.
On 7/28/06, nlif <na...@dbnet.co.il> wrote:
>
> Thanks, James.
>
> Sending just the URI is not an option in my case, since the participating
> applications do not share a file server (or a database, for that matter).
>
> As for the second suggestion, just to make sure I understand: do you mean
> that I should implement the equivalent of the ActiveMQ streams feature, by
> splliting the files into JMS ByteMessages and then include them in the
> MessageGroup and in the transaction? (btw I've looked at the Streams code,
> and I know this is pretty much what it does, only that the input stream
> auto-acknowledges each chunk, right?).
I mean split your transaction from sending many Mbs of data in 1
transaction to splitting the file into more manageable chunks and
having lots of littler transactions.
The other option is just to buy a big box with heaps of RAM :)
> Now, could there be a different approach to all of this? My whole problem
> stems from the fact I don't want to acknowledge ANY of the items (messages
> and/or files) until I have ALL of them. The reason is simple: if my cosumer
> crashes half-way, some data is lost. However, trying to sync the acks for
> all different items, that may be passed via different mechanisms, makes
> things very complicated for me.
>
> Is there another way? Is it possible to go back to simple MessageListeners
> and InputStream consumers, which acknowledge every item separately, but have
> a different mechanism for ensuring their state is recoverable? Maybe I
> should go for a consumer that can persist its data? Or is this even harder
> to achieve?
Why can't you acknowledge in batches; say a few 100K at a time?
> This seems to me like something many applications might require. Am I really
> the only one faced with a scenario in which a transmission is composed of
> several items, that cannot be sent as a single JMS message? Is there no
> generic solution for this?
For most of the customers I work with, their transaction boundaries
are reasonably small with 10-100K of data per transaction. If you need
to process something larger you can often split it up into smaller
chunks.
--
James
-------
http://radio.weblogs.com/0112098/
Re: Consuming a group of messages in a single transaction
Posted by James Strachan <ja...@gmail.com>.
Great idea :)
On 7/28/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> I'm thinking that it's use would look something like this on the producer
> side:
>
> message = new ActiveMQInputStreamMessage();
> message.setInputStreamFactory( new InputStreamFactory() {
> InputStream createInputStream() throws IOException {
> return new FileInputStream("/path/to/big/file/you/want/to/send");
> }
> });
> producer.send(message);
>
> and on the consumer side it would be like:
>
> message = (ActiveMQInputStreamMessage)consumer.receive();
> InputStream is = message.openInputStream();
> // use the InputStream to read the data.
> is.read();
>
> What do you think? The cool thing is that this would even work over topics
> since the producer would just read the file multiple times.
>
> On 7/28/06, James Strachan <ja...@gmail.com> wrote:
> >
> > On 7/28/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > At one point we were considering implementing an InputStreamMessage
> > which
> > > allowed a producer ship a consumer an 'InputStream'. Basically the
> > consumer
> > > would only be able to read the input stream while the the producer is
> > still
> > > online. The upside to this is that you get the benefits of sending the
> > big
> > > data out of band but still just using JMS network.
> >
> > Yeah. We could maybe do transactions between the producer and consumer
> > directly so if the consumer fails the transfer starts again from the
> > beginning etc.
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Consuming a group of messages in a single transaction
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I'm thinking that it's use would look something like this on the producer
side:
message = new ActiveMQInputStreamMessage();
message.setInputStreamFactory( new InputStreamFactory() {
InputStream createInputStream() throws IOException {
return new FileInputStream("/path/to/big/file/you/want/to/send");
}
});
producer.send(message);
and on the consumer side it would be like:
message = (ActiveMQInputStreamMessage)consumer.receive();
InputStream is = message.openInputStream();
// use the InputStream to read the data.
is.read();
What do you think? The cool thing is that this would even work over topics
since the producer would just read the file multiple times.
On 7/28/06, James Strachan <ja...@gmail.com> wrote:
>
> On 7/28/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > At one point we were considering implementing an InputStreamMessage
> which
> > allowed a producer ship a consumer an 'InputStream'. Basically the
> consumer
> > would only be able to read the input stream while the the producer is
> still
> > online. The upside to this is that you get the benefits of sending the
> big
> > data out of band but still just using JMS network.
>
> Yeah. We could maybe do transactions between the producer and consumer
> directly so if the consumer fails the transfer starts again from the
> beginning etc.
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Consuming a group of messages in a single transaction
Posted by James Strachan <ja...@gmail.com>.
On 7/28/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> At one point we were considering implementing an InputStreamMessage which
> allowed a producer ship a consumer an 'InputStream'. Basically the consumer
> would only be able to read the input stream while the the producer is still
> online. The upside to this is that you get the benefits of sending the big
> data out of band but still just using JMS network.
Yeah. We could maybe do transactions between the producer and consumer
directly so if the consumer fails the transfer starts again from the
beginning etc.
--
James
-------
http://radio.weblogs.com/0112098/
Re: Consuming a group of messages in a single transaction
Posted by Hiram Chirino <hi...@hiramchirino.com>.
At one point we were considering implementing an InputStreamMessage which
allowed a producer ship a consumer an 'InputStream'. Basically the consumer
would only be able to read the input stream while the the producer is still
online. The upside to this is that you get the benefits of sending the big
data out of band but still just using JMS network.
On 7/28/06, nlif <na...@dbnet.co.il> wrote:
>
>
> Thanks, James.
>
> Sending just the URI is not an option in my case, since the participating
> applications do not share a file server (or a database, for that matter).
>
> As for the second suggestion, just to make sure I understand: do you mean
> that I should implement the equivalent of the ActiveMQ streams feature, by
> splliting the files into JMS ByteMessages and then include them in the
> MessageGroup and in the transaction? (btw I've looked at the Streams code,
> and I know this is pretty much what it does, only that the input stream
> auto-acknowledges each chunk, right?).
>
> Now, could there be a different approach to all of this? My whole problem
> stems from the fact I don't want to acknowledge ANY of the items (messages
> and/or files) until I have ALL of them. The reason is simple: if my
> cosumer
> crashes half-way, some data is lost. However, trying to sync the acks for
> all different items, that may be passed via different mechanisms, makes
> things very complicated for me.
>
> Is there another way? Is it possible to go back to simple MessageListeners
> and InputStream consumers, which acknowledge every item separately, but
> have
> a different mechanism for ensuring their state is recoverable? Maybe I
> should go for a consumer that can persist its data? Or is this even harder
> to achieve?
>
> This seems to me like something many applications might require. Am I
> really
> the only one faced with a scenario in which a transmission is composed of
> several items, that cannot be sent as a single JMS message? Is there no
> generic solution for this?
>
> Naaman
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Consuming-a-group-of-messages-in-a-single-transaction-tf1966918.html#a5535203
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Consuming a group of messages in a single transaction
Posted by nlif <na...@dbnet.co.il>.
Thanks, James.
Sending just the URI is not an option in my case, since the participating
applications do not share a file server (or a database, for that matter).
As for the second suggestion, just to make sure I understand: do you mean
that I should implement the equivalent of the ActiveMQ streams feature, by
splliting the files into JMS ByteMessages and then include them in the
MessageGroup and in the transaction? (btw I've looked at the Streams code,
and I know this is pretty much what it does, only that the input stream
auto-acknowledges each chunk, right?).
Now, could there be a different approach to all of this? My whole problem
stems from the fact I don't want to acknowledge ANY of the items (messages
and/or files) until I have ALL of them. The reason is simple: if my cosumer
crashes half-way, some data is lost. However, trying to sync the acks for
all different items, that may be passed via different mechanisms, makes
things very complicated for me.
Is there another way? Is it possible to go back to simple MessageListeners
and InputStream consumers, which acknowledge every item separately, but have
a different mechanism for ensuring their state is recoverable? Maybe I
should go for a consumer that can persist its data? Or is this even harder
to achieve?
This seems to me like something many applications might require. Am I really
the only one faced with a scenario in which a transmission is composed of
several items, that cannot be sent as a single JMS message? Is there no
generic solution for this?
Naaman
--
View this message in context: http://www.nabble.com/Consuming-a-group-of-messages-in-a-single-transaction-tf1966918.html#a5535203
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Consuming a group of messages in a single transaction
Posted by James Strachan <ja...@gmail.com>.
On 7/28/06, nlif <na...@dbnet.co.il> wrote:
>
> Thanks, Hiram.
>
> I guess I need to take a step back then, and restate my question in a more
> generalized form: how is it possible in a JMS-based architecture to
> send/receive several seperate items, while ensuring atomicy of the group?
> That is - it is ensured that ALL items of the group are received, and by the
> SAME consumer.
>
> At first, I thought using JMS transactions (both on the producer and on the
> consumer side) will suffice, but then I realized in a cluster (or even a
> multi-threaded single-node consumer) the group might get scattered among
> several consumers.
>
> ActiveMQ MessageGroups then came to the rescue - I am using an AMQ group, as
> one would use a transaction, to ensure all items are delivered to the same
> consumer (and the consumer will commit only after it has received all items
> in the group).
>
> However, now with the need to pass very large binary files, for which I must
> use streams, it seems I am running out of options. Maybe it is time to
> rethink the whole concept... so, is there another architecture for such a
> requirement? Seems to me this is somewhat of a generic problem for any
> messaging-based archiecture, and I would think there is some
> "design-pattern" solution for it. Is there?
You could always make the large files available someplace via a URI
and send them out of band then use JMS transactions as you were doing
before but pass URIs to the massive files rather than the files
themselves. Or split the files up into chunks.
--
James
-------
http://radio.weblogs.com/0112098/
Re: Consuming a group of messages in a single transaction
Posted by nlif <na...@dbnet.co.il>.
Thanks, Hiram.
I guess I need to take a step back then, and restate my question in a more
generalized form: how is it possible in a JMS-based architecture to
send/receive several seperate items, while ensuring atomicy of the group?
That is - it is ensured that ALL items of the group are received, and by the
SAME consumer.
At first, I thought using JMS transactions (both on the producer and on the
consumer side) will suffice, but then I realized in a cluster (or even a
multi-threaded single-node consumer) the group might get scattered among
several consumers.
ActiveMQ MessageGroups then came to the rescue - I am using an AMQ group, as
one would use a transaction, to ensure all items are delivered to the same
consumer (and the consumer will commit only after it has received all items
in the group).
However, now with the need to pass very large binary files, for which I must
use streams, it seems I am running out of options. Maybe it is time to
rethink the whole concept... so, is there another architecture for such a
requirement? Seems to me this is somewhat of a generic problem for any
messaging-based archiecture, and I would think there is some
"design-pattern" solution for it. Is there?
Thanks,
Naaman
--
View this message in context: http://www.nabble.com/Consuming-a-group-of-messages-in-a-single-transaction-tf1966918.html#a5533929
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Consuming a group of messages in a single transaction
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Naaman,
Sending large streams in a transaction is not currently supported. The main
reason we did not want to support that is because currently all in progress
transaction have to be buffered in memory on the broker. Sending a large
stream could cause the broker OOM. If we change this in the future
(possibly by swapping the in progress transaction to disk), then I expect we
could support transacted streams.
On 7/27/06, nlif <na...@dbnet.co.il> wrote:
>
>
> Thanks James. I followed your advice and reworte my consumer as
> syncronous.
> This seems to be working quite well, but I do have two concerns:
>
> 1) In switching from async to sync consumers, I can no longer use Jencks
> as
> a container. This means I will need to implement some kind of
> thread-pooling
> myself, doesn't it? But I can still use Jencks for connection pooling, for
> both inbound and outbound, can't I?
>
> 2) In some cases, a group includes large files, for which I intended to
> use
> ActiveMQ streams. The problem is how to make the stream participate in the
> transaction (both on the producer and on the consumer side). That is, if
> my
> group includes 3 messages AND a file, then the consumer should only commit
> both the 3 messages and the file, or rollback for all of them. Is this at
> all possible? It seems to me like it isn't, since a stream API can't
> participate in a transaction. If so, is there another way for me to
> achieve
> both requirements: send several items as an atomic group (even across a
> cluster), AND send large files with low-memory footprint?
>
> Thanks,
> Naaman
> --
> View this message in context:
> http://www.nabble.com/Consuming-a-group-of-messages-in-a-single-transaction-tf1966918.html#a5518879
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Consuming a group of messages in a single transaction
Posted by nlif <na...@dbnet.co.il>.
Thanks James. I followed your advice and reworte my consumer as syncronous.
This seems to be working quite well, but I do have two concerns:
1) In switching from async to sync consumers, I can no longer use Jencks as
a container. This means I will need to implement some kind of thread-pooling
myself, doesn't it? But I can still use Jencks for connection pooling, for
both inbound and outbound, can't I?
2) In some cases, a group includes large files, for which I intended to use
ActiveMQ streams. The problem is how to make the stream participate in the
transaction (both on the producer and on the consumer side). That is, if my
group includes 3 messages AND a file, then the consumer should only commit
both the 3 messages and the file, or rollback for all of them. Is this at
all possible? It seems to me like it isn't, since a stream API can't
participate in a transaction. If so, is there another way for me to achieve
both requirements: send several items as an atomic group (even across a
cluster), AND send large files with low-memory footprint?
Thanks,
Naaman
--
View this message in context: http://www.nabble.com/Consuming-a-group-of-messages-in-a-single-transaction-tf1966918.html#a5518879
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Consuming a group of messages in a single transaction
Posted by James Strachan <ja...@gmail.com>.
On 7/19/06, nlif <na...@dbnet.co.il> wrote:
>
> Hi,
>
> I am using ActiveMQ's MessageGroups feature in order to send and receive
> several related messages as a single unit-of-work. I am using a transacted
> producer, so all messages are sent atomically, but I don't know how to
> implement the consumer.
Its actually the session which is transacted; which then implies the
producers and consumers created on the transacted session take part in
the same transaction.
> The way I see it - the consumer should accumulate
> the messages until it has all of them and then construct the aggregate, save
> it and only then - acknowledge them.
>
> Just to clarfiy, the problem I am trying to solve is that of the consumer
> crashing after acknowleding some, but not all, of the messages in the group.
> This will result in loss of messages.
If you want to consume several messages in a transaction, its
sometimes easiest to just use a consumer, pull all the messages out,
aggregate them and send them using JMS - as you are kinda doing a
custom 'transaction batch' using your own business logic to decide the
batch size.
e.g.
session = connection.createSession(true, 0);
consumer = session.createConsumer(destination);
while (true) {
m1 = consumer.receive();
...
mn = consumer.receive();
producer.send(someAggregationMessage);
session.commit();
}
> So I started-off with a MessageListener configured with Jencks, for pooling.
> The MessageListener should collect all messages in the group, and once it
> has all of them - it should acknowledge all of the together. Now, ensuring
> all messages are indeed delivered to the same MessageListener is taken care
> of by the MessageGroups feature. But since Jencks commits the transaction
> when the onMessage() method returns - this prevents me from acknowledging
> all messages together.
Yeah. Am wondering if we could add some custom batching plugin into
the Resource Adapter in ActiveMQ maybe - its a little tricky though
> I know some people throw a RuntimeException in the onMessage() method in
> order to make Jencks rollback, but that's awkward to say the least, since it
> will cause messages I already have to be redlivered again and again!
Yeah - if you are doing this kind of batch processing, you either have
to go with the whole batch being redelivered again - or you catch
errors and send bad messages to dead letter queues.
> Furthermore, if I am not mistaken, although all Jencks' threads share the
> same MessageListener instance, each message is (or may be) delivered by a
> different session. This means, that even if I did find a way to commit the
> transaction myself - it would still not achieve the behavior I need.
Yes - Jencks generally load balances messages across sessions; though
the batching feature in the ActiveMQResourceAdapter does AFAIK use the
same session for 1 batch.
--
James
-------
http://radio.weblogs.com/0112098/