Menu
We have a JMS queue which receives a very large number of messages.
Listener has to save message in database using a database transaction and then commit JMS transaction.
So how can i do it more effectively where i don't have to do database & JMS commit on each message.
301
JMS is the standard Java™ EE messaging API for building enterprise messaging applications. IBM® App Connect Enterprise provides built-in input and output nodes for its supported protocols.
JMS does not define order of message receipt across destinations or across a destination's messages sent from multiple sessions. This aspect of a session's input message stream order is timing-dependent. It is not under application control.
Don't do it on each message, do it in batches. JMS supports transactions just like your DB does; start a JMS transaction, read N messages. Start DB transaction, insert N messages. Commit to JMS, commit to DB.
This obviously introduces a window for a race to occur (crash happens between the two commits). You have that now, but only for a single message. If you want to solve that problem you're faced with either looking at XA transactions (two phased commit) or at the very least some sort of duplicate detection scheme. For some intro to that, take a look at: http://activemq.apache.org/should-i-use-xa.html
60
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
