CODEWITHSUNDEEP
javaspringtransactionsactivemq-classic
Kuldeep
Kuldeep

Reputation: 659

Transactions with multiple resources (database and JMS broker)

I have an application where we insert to database and we publish event to ActiveMQ.

I am facing problems with the transaction. I will explain the issue with the code below:

@Transactional(rollbackFor = Exception.class)
public class ProcessInvoice {

    public boolean insertInvoice(Object obj){

        /* Some processing logic here */

        /* DB Insert */
        insert(obj);

        /* Some processing logic here again */

        /* Send event to Queue 1 */
        sendEvent(obj);

        /* Send event to Queue 2 */
        sendEvent(obj);

        return true;
    }
}

Class is annotated with @Transactional, in the insertInvoice method I am doing some processing, inserting to DB, and sending event's to two queues.

With the above code I am facing two problems:

  1. If the queue is slow then I am facing performance issue as process takes time in sendEvent method.

  2. If for some reason ActiveMQ is down or consumer not able to process the message, how to rollback the transaction?

How to deal with these issue?

Upvotes: 1

Views: 605

Answers (2)

Justin Bertram
Justin Bertram

Reputation: 35008

If you need to send your message transactionally (i.e. you need to be sure the broker actually got your message when you send it) and the broker is performing slowly which is impacting your application then you only have two choices:

  1. Accept the performance loss in your application.
  2. Improve the broker's performance so that your application performance improves as well. Improving broker performance is a whole other subject.

In JMS (and most other messaging architectures) producers and consumers are unaware of each other by design. Therefore, you will not know if the consumer of the message you send is unable to process the message for any reason, at least not through any automatic JMS mechanism.

When the broker is down the sendEvent method should fail outright. However, I'm not terribly familiar with how Spring handles transactions so I can't say what should happen in that regard.

Upvotes: 1

Reubems
Reubems

Reputation: 51

I have some questions regarding your issue:

  • If the sendEvent(Object o) method is that expensive (according to what you say) in terms of performance, why do you consider to call it twice (apparently for processing the same object)?

Apparently the result of those 2 calls would be the same, with the difference that they would be sent to 2 different queues. I believe that you could send it to both queues in just one call, in order not to execute the same code twice.

  • When thinking in transactions, the first things that come to my head are synchronous operations. Do you want to perform those operations asynchronously or synchronously? For example, do you want to wait until the invoice is inserted in the DB for sending right after the message to Queue1 and Queue2?

Maybe you should do it asynchronously. If you don't or cannot, maybe you could opt for an "optimistic" strategy, where you send first the message to Queue1 and Queue2, and afterwards while you are processing those messages on the broker side, you perform the insertion of the invoice into the DB. If the database has a high availability, in most cases the insertion will succeed, so you will not have to wait until it is persisted to send the messages to Queue1 and 2. In case the insertion did not succeed (what would be very unlikely), you could send a second message to undo those changes on the broker side. In case that due to your business logic this "undo" process is not trivial, this alternative might not suit for you.

You mention if ActiveMQ is down, how to rollback. Well, in that case maybe you need some monitoring of the queues to find out if the message reached its destination or not. I would advise you to take a look to the Advisory messages, they may help you to control that and act in consequence.

But maybe what you need could also be re-thought and solved with durable subscribers, in that way once the subscribers were available again, they would receive that message that was en-queued. But this performs slightly worse since it needs to persist the messages to files to recover them afterwards if the broker goes down.

Hope these suggestions help you, but in my opinion I believe you should describe more how should it be the result you want (the flow) since it does not seem to be very clear (at least to me)

Upvotes: 0

Related Questions