Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Why using BTM

There are two different arguments here:

  1. Why would I need a transaction manager ?
  2. Why using BTM and not insert your favorite TM here ?

Why would I need a transaction manager ?

If you either use two databases (or more) in your application or you use both a database and JMS then you need a transaction manager. Some people will argue that you can do without one even if you fall in on of those two cases. They are true: it is possible to have a transaction span two resources (like JMS and JDBC) by writing so-called idempotent methods manipulating these resources.

Idempotent definition


A unary operation is idempotent if, whenever it is applied twice to any element, it gives the same result as if it were applied once.

The fact is that it is usually harder to write idempotent methods and you also have to write some recovery logic to handle crash cases. Why would you have to accept those constraints when you can get free of them ? And why would you have to be careful about low-level logic in your code when you can delegate it to an component specialized in this task ?

It is the transaction manager's job to make sure consistency is kept across disparate resources, not yours.

Why using BTM and not insert your favorite TM here ?

In short: because it is complete and easy to use.

BTM has been tailored to support only the most common scenarios, it's internal logic is kept as simple as possible to only support them. On the other hand, great care has been taken to make those scenarios working as easily and as best as possible.

Some recently open-sourced transaction managers are more feature-complete than BTM. None of them come close to BTM's ease of use.

  • No labels