Atomikos transaction test jms

Question

I have an issue concerning JMS. They are retrieved from an event database and sent via ActiveMQ broker to an ESB.

When JMS are sent they are marked as sent in the event database. The process is supposed to be transactional.

However, I noticed that som JMS were marked as sent while they were not received. I've studied this issue and noticed that distributed transactions were not implemented which led to the loss of JMS. They were marked as sent in event database but the ESB to which they were sent threw an error and JMS was not received.

At that point database transaction should have been rollbacked but it is not as both transaction were not managed.

I implemented Atomikos transaction coordinator to handle both transactions. Now I'd like to test my new configuration.

I heard there was a way to test both transactions handling but I found no examples. Do you have any idea or example ?

Technologies : Spring Integration, ActiveMQ, Atomikos

Answer 1

See the Spring Documentation. The same techniques apply.

One common issue in tests that access a real database is their effect on the state of the persistence store. Even when you’re using a development database, changes to the state may affect future tests. Also, many operations — such as inserting or modifying persistent data — cannot be performed (or verified) outside a transaction.

The TestContext framework addresses this issue. By default, the framework will create and roll back a transaction for each test. You simply write code that can assume the existence of a transaction. If you call transactionally proxied objects in your tests, they will behave correctly, according to their configured transactional semantics. In addition, if a test method deletes the contents of selected tables while running within the transaction managed for the test, the transaction will roll back by default, and the database will return to its state prior to execution of the test. Transactional support is provided to a test via a PlatformTransactionManager bean defined in the test’s application context.

If you want a transaction to commit — unusual, but occasionally useful when you want a particular test to populate or modify the database — the TestContext framework can be instructed to cause the transaction to commit instead of roll back via the @Commit annotation.

See transaction management with the TestContext framework.