Concurrency issuesAdded by IBM on September 9, 2010 | Version 1 (Original)
|Concurrency refers to the sharing of resources by multiple interactive users or application programs at the same time. DB2® Everyplace® supports concurrent transactions, enabling an application to establish several distinct connections to the same database.
refers to the sharing of resources by multiple interactive users or application programs at the same time. DB2® Everyplace® supports concurrent transactions, enabling an application to establish several distinct connections to the same database.
When developing such an application, take care to prevent undesirable effects, such as:
- Lost updates. Two applications, A and B, might both read the same row from the database and both calculate new values for one of its columns based on the data these applications read. If A updates the row with its new value and B then also updates the row, the update performed by A is lost.
- Access to uncommitted data. Application A might update a value in the database, and application B might read that value before it was committed. Then, if the value of A is not later committed, but backed out, the calculations performed by B are based on uncommitted (and presumably invalid) data.
- Non-repeatable reads. Some applications involve the following sequence of events: application A reads a row from the database, then goes on to process other SQL requests. Meanwhile, application B either modifies or deletes the row and commits the change. Later, if application A attempts to read the original row again, it receives the modified row or discovers that the original row has been deleted.
- Phantom reads. The phantom read phenomenon occurs when:
- Your application executes a query.
- Another application inserts or updates data that satisfies your application's query criteria.
- Your application repeats the query from step 1 (within the same unit of work), but the result set is different because it includes additional "phantom" rows inserted or updated by the other application.
You can prevent such behavior in a DB2 Everyplace application by managing locks and isolation levels. If your application does not require multiple database connections, you can avoid concurrency issues altogether by disabling shared access. For example, the connect method in the java.sql.Driver interface supports ENABLE_SHARED_DATABASE_ACCESS, a Boolean property that you can set to false to disable concurrent access.
Parent topic: Tuning database applications: XPD622