Network Deployment (Distributed operating systems), v8.0 > Reference > Developer examples
Example: Read-read consistency checking
Read-read consistency checking only applies to LifeTimeInCache beans whose data is read from another transaction.
Usage scenario
For the access intents that are for repeatable read (RR), this means the product checks that the data is consistent with that in the data store and ensures that no one updates it after the checking. For the Access Intents that are for read committed (RC), this means the product checks that the data is consistent at the point of checking, but it does not guarantee that the data does not change after the checking. This makes the behavior of the LifeTimeInCache bean the same as non-LifeTimeInCache beans.
You have three options for setting consistency checking, as shown in the following scenarios concerning the calculation of interest in "Ann's" bank account. In each case, the data store is shared by this EJB container managed persistence (CMP) application to calculate the interest and other applications, such as EJB bean managed persistence (BMP) , JDBC, or legacy applications. Also in each case, the EJB account is configured as a long-lifetime bean.
NONE
- The server is started.
- User 1 in Transaction 1 calls Account.findByPrimaryKey("10001"), account data for Ann is read from the database, with a balance of $100.
- Ann’s record is cached by the persistence manager (PM) on the server.
- User 2 writes a JDBC call and changes the balance to $120.
- User 3 in Transaction 2 calls Account.findByPrimaryKey() for account "10001", Ann’s data is read from cache, with a balance of $100.
- Calculate Ann’s interest, but the result might not be correct because of the data integrity issue.
Read-read checking AT_TRAN_BEGIN
- The server is started.
- User 1 in Transaction 1 calls Account.findByPrimaryKey("10001"), account data for Ann is read from the database, with a balance of $100.
- Ann’s record is cached by the persistence manager (PM) on the server.
- User 2 writes a JDBC call and changes the balance to $120.
- User 3 in Transaction 2 calls Account.findByPrimaryKey() for account "10001", Ann’s data is read from cache, with a balance of $100.
- PM performs read-read check on Ann's account and finds that the balance of 100 is changed. It issues a database query to retrieve balance of $120, and Ann’s data in the cache is refreshed.
- Calculate Ann’s interest, proceed with the transaction because data integrity is protected.
Read-read checking AT_TRAN_END
- The server is started.
- User 1 in Transaction 1 calls Account.findByPrimaryKey("10001"), account data for Ann is read from the database, with a balance of $100.
- Ann’s record is cached by the persistence manager (PM) on the server.
- User 2 writes a JDBC call and changes the balance to $120.
- User 3 in Transaction 2 calls Account.findByPrimaryKey() for account "10001", Ann’s data is read from database, with balance of $100.
- Calculate Ann’s interest.
- During end of transaction 2, PM performs read-read check on Ann's account and finds that the balance of 100 is changed.
- PM rolls back the transaction and invalidates the cache. The transaction fails and again data integrity is protected.
Enterprise beans
Concurrency control
Develop applications that use JNDI
Related
WebSphere extensions to the EJB specification
Enterprise bean development best practices