Assuming you want to know the meaning of transaction -
EJB transactions are a set of concepts and a set of mechanisms that attempt to insure the integrity and consistency of a database for which multiple clients may attempt to access it and/or update it simultaneously.
An Entity EJB is a representation of business data. Its state is represented completely by the values of its persistent instance variables, that is, those that are synchronized with the persistent store (database). If a transactional operation in such an Entity EJB fails, then the system considers it to have been successfully rolled back if its underlying business data is put back to its pre-transactional state. Instance variables that do not represet data in the persistent store cannot be restored. If the EJB has container-managed persistence, then all the synchronization of the variables with the persistent store will be automatic, even after a rollback. This takes some work away from the developer, but it does imply that the EJB must be no more than an object representing a database row.
Because of the assumption above, transaction management in Entity EJBs should never be under programmer control. The EJB 2.0 specification prohibits an Entity EJB from managing its own transactions; the container must do everything. Therefore, if your transaction management requirements are beyond those offered by the container, then you can't use Entity EJBs at all. Of course, the EJB paradigm says that an Entity EJB is simply a model of business data and, as such, will never need a more complicated transaction mechanism than that offered by the container.
Where Entity EJBs are involved in a transaction, the Entity EJBs' methods will normally be called by a method in a Session EJB.
Transactions can be managed by the container; in this case the developer's role is to specify the correct declarative transaction attributes in the deployment descriptor. Only very limited programmatic control of transactions is allowed. Entity EJBs MUST use this mechanism. Alternatively, a Session EJB can opt to manage its own transactions programatically. Because a Session EJB s not just a model of business data, the container can only offer limited support for transaction management, as will be discussed. This means that if the Session EJB has a state that will change during a transaction (e.g., instance variables will change value), then the developer has to provide support for this, even in container-managed transactions. The EJB API provides the SessionSynchronization interface for this.
Basic properties of transactions can be summarized using the ACID mnemonic:
Atomic
All or nothing. If a transaction is interrupted, all previous steps within that transaction are undone.
Consistent
The state of objects and/or the state of tables within a database move from one consistent state to another consistent state.
Isolated
What happens within one transaction should not affect or be visible within another transaction.
Durable
The effects of a transaction are persistent.
Local and global transactions
Local transactions – All operations are carried out on a same database.
All modern database engines can handle transactions access to their own data stores. A local transaction is exactly that: it is confined to a single process executing against a single database server.
Distributed transactions – Operations are carried out with multiple servers, two-phase commit protocol is used, need "transaction manager" for coordinating two-phase commit protocol.
However, in more sophisticated systems a transaction may encompass multiple database servers, perhaps from different vendors and with different protocols. A transaction that can handle multiple databases is called a global (or distributed) transaction; if the servers are different (in vendor, or protocol) this is called a heterogenous global transaction.
A single database server cannot handle global transactions; neither is there direct support in the JDBC specification, because it operates at the level of an individual database connection. Generally we need a transaction manager to control global transactions. The Java Transaction API (JTA) provides access to the services offered by a transaction manager. If EJBs require control of global transactions, they can get access to JTA via the container.
Source: http://java.boot.by/ibm-287/ch05.html
