how the Transaction concept is implemented in EJB

Question

I wan to know how the transaction is internally implemented in EJB. I want to know the logic they use to create a transaction. if you could point out some articles that would be helpful

Answer 1

Hibernate has TransactionFactory:

An abstract factory for Transaction instances. Concrete implementations are specified by hibernate.transaction.factory_class.

It has implementations: JDBCTransactionFactory, JTATransactionFactory, CMTTransactionFactory. These factories create an instance of Transaction - for example JDBCTransaction.

Then I can't tell you what happens for JTA and CMT, but for JDBC it's as simple as setting the auto-commit to false (when you call begin a transaction):

connection.setAutoCommit(false);

And respectively on transaction.commit(): connection.commit()

If any exception occurs when operating with the session, it invokes connection.rollback()

Answer 2

Hibernate doesn't implement transactions, it relies on and wraps JDBC transactions or JTA transactions (either container managed or application managed).

Regarding EJBs, if you want to understand the details of a JTA Transaction Manager, you'll need to be fluent with the JTA interfaces UserTransaction, TransactionManager, and XAResource which are described in the JTA specification. The JDBC API Tutorial and Reference, Third Edition will also be useful to understand the XA part of a JDBC driver.

Then, get the sources of an EJB container (like JBoss) or of a standalone JTA Transaction Manager (like Atomikos) to analyze the TM part. And good luck.

Answer 3

From EJB in Action book

The protocol commonly used to achieve multiple resource is the two-phase commit. The two-phase commit protocol performs an additional preparatory step before the final commit. Each resource manager involved is asked if the current transaction can be successfully committed. If any of the resource managers indicate that the transaction cannot be committed if attempted, the entire transaction is abandoned (rolled back). Otherwise, the transaction is allowed to proceed and all resource managers are asked to commit.

A resource manager can be a database, for instance. Others examples includes a Message Service. The component which coordinates transactions is called Transaction manager.

Suppose you have an application which involves two distincts databases. How does Transaction manager performs its work by using Two phase commit protocol ?

1. Transaction Manager ask database 1 if it can commit the current transaction
2. If so, ask database 2 if it can commit the current transaction
3. Transaction Manager ask database 1 to commit
4. Transaction Manager ask database 2 to commit

Hibernate is built on top of the JDBC API. It just coordinates one database. So if you call

session.commit();

Behind the scenes, it call

connection.commit();

If you really want to study Transaction internals, my advice is Java Transaction Processing book.

Answer 4

This question could have answers at many levels.

A general discussion of what's going on can be found here

My summary goes like this ... First, somewhere there must be a transaction coordinator, the EJB container will know about the coordinator - typically that's part of the application server. So all the EJB container has to do is to call

someobject.BeginTransaction()

that's it. The actual API the EJB container uses is JTA. EJBs can actually use Bean Managed transaction transaction or Container managed transactions. In the Bean Managed case the implementer nhas to make the JTA calls. More usually we use Container Managed transactions (CMT). In which case the container has logic which is run before the implementation is reached. For example:

if ( we're not already in a transaction )
    begin transaction

call the EJB implementation

and later the container has logic

if ( finished processing request )
    commit transaction

with other paths to abort the transaction if errors have happened.

Now that logic is more complex because CMT EJBs are annotated with transaction control statements. For example you can say things "if we already have a transaction, use it" So if one EJB calls another only a single transaction is used. Read up the EJB spec for that.

However all that's pretty obvious in any write-up of JEE EJBs. So I suspect that you're asking moe about what happens inside the JTA calls, how the transaction manager is implemented and its relationship to the transactional resource managers (eg. Databases). That's a huge topic. You've actually go implementations of the XA distributed transaction protocol down there. Frankly I doubt that you really need to need to know this. At some point you have trust the APIs you're using. However there is one key detail: your Transaction Manager (typically the App Server itself) must be able to tell the REsource Managers the fate of any given transaction, and that information must survive restart of the App Server, hence some persistent store of transaction information must be kept. You will find transaction logs somewhere, and in setting up the App Server you need to make sure those logs are well looked after.

Answer 5

Another good read would be the JTS articles by Brian Goetz; links:

1. http://www.ibm.com/developerworks/java/library/j-jtp0305.html
2. http://www.ibm.com/developerworks/java/library/j-jtp0410/index.html
3. http://www.ibm.com/developerworks/java/library/j-jtp0514.html