Nested transaction

Collection of sub tasks or sub transactions Each such sub transaction may be having several other sub transactions With reference to a database transaction, a nested transaction occurs when a new transaction is started by an instruction that is already inside an existing transaction. The new transaction is said to be nested within the existing transaction, hence the term. This feature is DBMS dependent and is not available for all databases. Moss developed Nested transaction model Nesting of transactions form a tree or hierarchy like structure At the top level there is parent transaction Having childs as sub transactions These childs may also posses other sub transactions as well The DB operations are performed only by the leaf-level transactions Transaction abort at one level should not affect the progress at higher level

Isolation Property: Nested transactions are implemented differently in different databases. However, they have in common that the changes are not made visible to any unrelated transactions until the outermost transaction has committed. Committed updates of a sub transaction is only visible to its immediate parent This means that a commit in an inner transaction does not necessary persist updates to the database. In some databases, changes made by the nested transaction are not seen by the 'host' transaction until the nested transaction is committed. This follows from the isolation property of transactions.

Recovery To avoid this parent transaction has to perform following tasks i. Ignore the failure by considering the sub transaction as non vital ii. Abort iii. Retry iv. Run alternative / contingency sub transaction

Concurrency Control: Moss also proposed the concurrency control for the transactions He has used strict two phase commit for the same Sub transaction of a parent is allowed to execute only if it is separate transaction Sub transaction is allowed to hold lock only if it hold by its parent As soon as sub transaction commits , parent will inherit the lock Parent will hold the lock in exclusive mode if it is on same data item

Advantages: Modularity: i. Different sub transactions ii. For the purpose of recovery and concurrency control Concurrency Control & Recovery: i. Performed at sub transaction level

ii. Rather that at transaction level Parallelism i. Sub transactions are executed parallel Recovery: i. Uncommitted sub transactions are aborted ii. Without affecting other transactions

Flat Transactions
Flat transactions represent the simplest type of transaction, and for almost all existing systems, It is the only one that is supported at the application programming level. A flat transaction is the basic building block for organizing an application into atomic actions. It can contain an arbitrary number of simple actions: these actions may, in turn, be either protected, real, or even unprotected, if necessary. Putting a flat transaction as an execution unit around a sequence of either protected or real actions makes the whole appear as indivisible as far as the application is concerned. These transactions are called flat because there is only one layer of control by the application. Everything inside the BEGIN WORK and COMMIT WORK brackets is at the same level; that is, The transaction will either survive together with everything else (commit), or it will be rolled back with everything else (abort). The major restriction of flat transactions is that there is no way of either committing or aborting parts of such transactions, or committing results in several steps, and so forth. Advantages: Easy to implement. Supported by all database systems.

Limitations: Only total rollback (abort) is possible

Partial rollback not possible All work lost in case of crash Limited to accessing a single DBMS Entire transaction takes place at a single point in time

Differences between Pessimistic and Optimistic Locking

Locking: Locking is an RDBMS feature that prevents users from different transactions from causing data conflicts. When locking is acquired on a row, it prevents other transactions from changing that row until the transaction ends
Transactional isolation is usually implemented by locking whatever is accessed in a transaction.

Pessimistic locking:
Most Oracle developers are already familiar with pessimistic locking, which was the default locking in BC4J (now optimistic is the default in 11.1.2.x)). This means that the row is locked in advance once one of its attribute is changed through a call to setAttribute() method. If anyone else attempts to acquire a lock of the same row during this process, he will be forced to wait until the first transaction has completed. This is achieved by using the familiar SELECTFOR UPDATE syntax. This is the safest locking mode because two transactions will never make inconsistent change to the same row.

Disadvantages:

1. If a user selects a record for update, and then leaves for lunch without finishing or aborting the transaction. All other users that need to update that record are forced to wait until the user returns and completes the transaction, or until the DBA kills the offending transaction and releases the lock. 2. The Deadlock Users A and B are both updating the database at the same time. User A locks a record and then attempt to acquire a lock held by user B who is waiting to obtain a lock held by user A.

Pessimistic locking, which is the default, should not be used for web applications as it creates pending transactional state in the database in the form of row-level locks.
it may cause lock contention

If pessimistic locking is set, state management will work, but the locking mode will not perform as expected. Behind the scenes, every time an application module is recycled, a rollback is issued in the JDBC connection. This releases all the locks that pessimistic locking had created.

Example 1: An example about pessimistic locking based on well known hr schema, suppose user1 and user2 are two different users (two distinct transactions) using pessimistic locking, both of them try to change the same row of data as follows:

1. User1 calls EmployeesImpl.setSalary(1000) on a particular row, so user1 immediately acquire a lock on that row. 2. Now user2 calls EmployeesImpl.setSalary(2000) on the same row, user2 tries to acquire a lock on the row and receives oracle.jbo.AlreadyLockedException. Example 2: In the banking application example, an account is locked as soon as it is accessed in a transaction. Attempts to use the account in other transactions while it is locked will either result in the other process being delayed until the account lock is released, or that the process transaction will be rolled back. The lock exists until the transaction has either been committed or rolled back. ==================================================================

Optimistic Locking:

Optimistic locking assumes that multiple transactions can complete without affecting each other.
With optimistic locking, a resource is not actually locked when it is first is accessed by a transaction.

Instead, the state of the resource at the time when it would have been locked with the pessimistic locking approach is saved. Other transactions are able to concurrently access to the resource and the possibility of conflicting changes is possible. At commit time, when the resource is about to be updated in persistent storage, the state of the resource is read from storage again and compared to the state that was saved when the resource was first accessed in the transaction. If the two states differ, a conflicting update was made, and the transaction will be rolled back. Oracle recommends using optimistic locking for web applications. Instead of locking a row as soon as it is changed, under optimistic locking, BC4J waits until changed row is posted before attempting to acquire a lock. An exception is not thrown until the conflicting transactions attempt to post their changes to the database.

Example:

 Suppose user1 and user2 are two different users (two distinct transactions) using optimistic

locking, both of them try to change the same row of data as follows: 1. User1 calls EmployeesImpl.setSalary(1000) on a particular row, user1 does not immediately acquire a lock on that row. 2. User2 calls EmployeesImpl.setSalary(2000) on the same row. User1 and User2 now have different entity cache for the same row. 3. User2 calls commit() action, as part of the commit cycle the changed row is posted to the database. Before the update can be executed, user2 acquires a lock on that row. The lock expires immediately, when the commit command is sent to the database. 4. User1 now calls commit() action, BC4J tries to post the changed row to the database, right before posting it, it attempts to acquire a lock on that row. BC4J recognizes that the row has been changed by another user and that updating the row would overwrite another transactions changes, so it throws an oracle.jbo.RowInconsistentException.

Example: In the banking application example, the amount of an account is saved when the account is first accessed in a transaction. If the transaction changes the account amount, the amount is read from the store again just before the amount is about to be updated. If the amount has changed since the transaction began, the transaction will fail itself, otherwise the new amount is written to persistent storage. Finally, Whatever you use, you can lock a row at any time by calling EntityImpl.lock() on the corresponding entity object instance, even if the locking mode is optimistic.

Main-Memory Database

Main-Memory Database Optimizations

TP Monitor Architectures (Cont.)

TP Monitor Architectures

TP Monitor Architectures (Cont.)

DBMS Cache
The Database Management System (DBMS) is a memory buffer which stores copies of portions of the database that the DBMS is currently using. Reading from memory is much faster than reading from the disk. The DBMS therefore returns a record more quickly if it is already stored in cache. As long as the required data is stored in cache, the data is immediately available. When the required data is not stored in cache, it must be copied from the disk and then stored in cache.

DBMS Cache Transparency

The DBMS cache is transparent to the user. For example, when a user requests data, the data is automatically copied into the cache and stored there. If the data is modified, it is automatically copied back to the physical disk. These data transfers take place automatically. The user does not need to know about the cache. For example, three users send requests to the DBMS. When user 2 sends a request to read data from the database, the request handler determines whether the desired data can be fetched directly from the cache or whether it must be fetched from a disk.

At the same time, another user can modify a record in a table in the database. The modified data will be written to the DBMS cache, and not to the disk. When this user completes the write transaction (that is,

commits the changes), the data in the cache that was modified during the transaction is written to the disk. The cache is then said to be flushed. The DBMS cache always contains the most recently used data. The cache is continually updated with the relevant data from the database. The size of the cache greatly affects performance. When you set the size of the cache, you must remember two simple rules:

The more memory you assign to the cache, the more efficient it becomes. (Of course, there is no reason to assign more memory to the cache than the total size of your database.) The size of the cache must not exceed the amount of physical memory available on your system. This is because the operating system may swap the cache memory in and out of the disk. This will considerably slow down overall performance.