introduction

 

BERSERK's architecture is ready to be extended in many ways. Transaction is just one of the possibilities.

 

A transaction object is responsible for assuring a certain isolation level to storage data.

 

In BERSERK two transactional object are used: one to handle BERSERK's filters, chains and services defitions operations and another to handle application's domain data manipulation. Obviously they can be instances of the same class, or even the same instance (if following the Singleton design pattern).

 

In BERSERK V1.0 no write methods are available in BERSERK's DAO, so transaction handling is not a preocupation. However, the application may have transactional needs, and therefore a transactional object must be implemented.

 

BERSERK ships with two transactional objects: the Empty implementation that does absolutelly nothing, and the OJB implementation that uses OJB's Transaction object.

 

The beginTransaction(), abortTransaction() and the commitTransaction() are calledback by BERSERK framework. The other methods (for example the lockWrite() method) must be called explicitly by the developers.

 

public interface ITransactionBroker
{
	public void beginTransaction() throws StorageException;
	public void commitTransaction() throws StorageException;
	public void abortTransaction() throws StorageException;
	public void lockRead(List list) throws StorageException;
	public void lockRead(Object obj) throws StorageException;
	public void lockWrite(Object obj) throws StorageException;	
}