T R A N S A C T I O N S  

Client Transactions 

A client can begin and end a transaction by getting the UserTransaction from the naming 

server, begin and then commit or roll back the transaction at the end. In JBoss there are two 

different user transactions: a fast, in VM implementation for clients executing in the 

server VM, and a remote implementation that works for thin remote clients. 

A client can begin and end a transaction by getting the UserTransaction from the naming 

server, begin and then commit or roll back the transaction at the end. In JBoss there are two 

different user transactions: a fast, in VM implementation and a remote implementation able 

to work for remote clients. 

Transaction Isolation and Locking 

Transactions should be isolated from each other to avoid conflicts because a transaction in 

progress could change data that another transactions depend on. In J2EE there are four 

different levels of isolation: 

Read uncommitted: a transaction can read changes made by another transaction even 

not committed or rolled back. 

Read committed: a transaction cannot read any changed by another transaction until 

it is committed. 

Repeatable reads: a transaction cannot change data read by another transaction 

Serializable: a transaction has exclusive read and write access to the data it is using. 

Note that even though these isolation levels are specified by the J2EE specification the 

implementation depends heavily on the underlying database. Thus, even on the same 

application server with different databases you may observe slightly different behaviors. 

Deadlocks 

Because of transaction and method isolation it is possible to create an application deadlock. 

When a thread  1  calls bean  A  and another thread  2  calls bean  B  then  1  tries to call 

bean  B  and  2  tries to call bean  A  we have a deadlock because both tries to call another, 

already locked bean and none of them can give their lock. 

59