Locking 

Use

The EJB architecture provides shared access to the scarce resources, and mechanisms for avoiding conflicts when different applications or clients access one and the same resource. The shared access for container-managed entity beans is managed by the locking concept.

The locking mechanism in SAP J2EE Engine provides concurrency control and a consistent view of the entities in the database. It ensures the synchronization of the entity objects that are accessed concurrently from multiple transactions. This mechanism also provides better application performance and scalability according to the specifics and the business logic of the application.

Integration

The locking strategy in the SAP J2EE Engine EJB architecture is managed by the Persistence Manager. For more information about the functions of the Persistence Manager, see the SAP J2EE Engine EJB Architecture.

Features

The SAP J2EE Engine EJB Container provides several locking strategies and mechanisms to fulfill the needs of different applications or clients, which require access to the same data concurrently.

The EJB Container implements a pessimistic locking strategy, that is, transactions lock the entities in the persistent storage before modifying these entities, and unlock them when the transaction is over. The container provides the following types of locking mechanisms – Enqueue Server locking and database locking, which can be used by different business scenarios.

Enqueue Server Locking

The locks are managed by the Enqueue Server. With this type of locking, when a transaction tries to access an entity that is already locked by another transaction, an exception is thrown and the second transaction is rolled back.

This locking provides a higher degree of concurrency by avoiding the use of database locking mechanisms. Thus, you can achieve higher performance but your application may need to deal with exceptions if conflicting updates are attempted. In such cases, the failed transaction must be executed again. This type of locking provides the following advantages:

·        Better performance and scalability

·        The Enqueue Server keeps the locks and thus avoids using the slower database locking mechanisms

·        Common locking mechanism for all applications that use different kinds of Java persistency mechanisms (container-managed persistency, JDO, SQLJ, JDBC)

You can choose between three types of Enqueue Server locking: Table, Local, and Administrative. For more information, see Choosing the Type of Enqueue Server Locking.

You can also specify different logical isolation levels for every business operation. For more information, see Isolation Levels.

The Enqueue Server locking mechanism guarantees the data consistency and synchronization only if all applications that access the data in the persistent storage are deployed and running on SAP J2EE Engine. That is, if other applications access the same data and do not use the Enqueue Server, this locking will not guarantee the data consistency and you must use the database locking concept described below.

Database Locking

Database locking provides a common locking mechanism for all applications and clients that use the data stored in the database. When a transaction attempts to access a resource, it first locks the resource. If the resource is already in use (that is, it is locked) by another transaction, the second transaction waits until the first transaction commits and unlocks the resource, and then in turn accesses the resource. This mechanism is more reliable than the Enqueue Server locking and guarantees that only one transaction has exclusive access to the data in the persistent storage. However, this locking is slower and the applications that use it may decrease in performance.

You can use database locking when your application requires a very high transaction isolation. With database locking, the transactions are serialized (that is, they pass consecutively when accessing shared resources). This serialization is the highest possible isolation level between transactions.

The database locking is managed by the EJB Container using SELECT… FOR UPDATE queries. As this syntax is database-specific, first check whether the database you are using supports such queries.

Do not specify database locking if your container-managed entity bean uses an Open SQL DataSource, because the EJB Container will execute database-specific queries that the OpenSQL engine will not be able to resolve.

For more information how to enable the database locking, see Enabling Database Locking.

Finder-Method Locking

When they are executed, finder/select methods can explicitly lock the entity beans they access. That is, if you enable the finder-method locking for a specific finder/select method, all fields of the bean are loaded from the database (otherwise, only the primary key fields are retrieved from the database). This locking ensures that until the end of the transaction, the loaded data will remain consistent with the last state of the data in the database and avoids the same data being reloaded when the transaction uses it again later.

This option is useful when you want to select a large amount of data and then modify it, because it decreases the number of database access calls. However, be careful when loading and locking a large amount of objects, because the loading operation will be very slow and you will lock the objects in the database, thus preventing other applications or clients from using it.

When you use database locking for your entity beans, you do not need to set locks with your finder/select methods. Therefore, to optimize your finder/select queries, choose only whether to load or not to load the selected objects – they will be automatically locked when they are loaded.

When you use Enqueue Server locking, you can choose between setting read or write locks with your finder/select queries.

For information about how you enable the different finder-method locking options, see the Optimizing the Finder and Select Queries section in Specifying the Deployment Properties of Finder/Select Queries.