Transaction
Read Uncommitted (Dirty Reads)
Transaction 2 has changed a row, but has not committed the changes. Transaction 1 reads the uncommitted data but his view of the data may be wrong if Transaction 2 rolls back his changes and updates his own changes to the database.
Transaction A begins.
UPDATE employee SET salary = 31650
WHERE empno = '000090'
Transaction B begins.
SELECT * FROM employee
(Transaction B sees data updated by transaction A. Those updates have not yet been committed.)
Read Committed (Non-repeatable reads)
if Transcation T1 reads a row and Transcation T2 changes the same row, when T1 rereads and sees the changes made by T2.Then this is Non - Repeatable Read
ransaction A begins.
SELECT * FROM employee
WHERE empno = '000090'
Transaction B begins.
UPDATE employee SET salary = 30100
WHERE empno = '000090'
(Transaction B updates rows viewed by transaction A before transaction A commits.) If Transaction A issues the same SELECT statement, the results will be different.
Repeatable reads (phantom reads)
If Transcation T1 retrieves a bunch of rows.Transcation T2 inserts a row,T1 rereads the query and if T1 see the additional row, it is a ghost row to T1 then this is called as Phantom Read
Transaction A begins.
SELECT * FROM employee
WHERE salary > 30000
Transaction B begins.
INSERT INTO employee
(empno, firstnme, midinit,
lastname, job,
salary) VALUES ('000350', 'NICK',
'A','GREEN','LEGAL COUNSEL',35000)
Transaction B inserts a row that would satisfy the query in Transaction A if it were issued again.
Pessimistic Locking & Optimistic Locking
In pessimistic locking transaction locks the record as soon as it selects the row to update. While in optimistic locking it is only locked when the actual updating takes place.
Select name from emp where eno=1 for update; (Pessimistic)
Update emp set eno=’xxx’ where eno=1; (Optimistic)
Shared Lock
It permits other transaction to read the locked data but prevent be transaction from modifying the data.
Update Lock
Update lock prevents any other transaction to update the data. When a transaction tried to update data update lock converts to an exclusive lock.
Read Lock
A read lock is lock placed on a resource that is being read or accessed by a transaction. Read lock prevents other transaction to read or update the data which is locked be a read lock.
Exclusive Lock
A transaction places an exclusive lock on data when it is modifying the data. The lock prevents other transaction from reading or updating the locked data. The data remains locked until the transaction is committed or rolled back.
How do you rollback a container managed transaction in EJB?
SessionSynchronization
public class MyBean implements SessionBean, SessionSynchronization{
public int oldVal ; public int val ;
public void ejbCreate(int val) throws CreateException {
this.val=val;
this.oldVal=val;
}
public void afterBegin() { this.oldVal = this.val ;}
public void beforeCompletion(){};
public void afterCompletion(boolean b) { if (b == false) this.val = this.oldVal ; }
.......................................
}
public interface javax.ejb.SessionSynchronization {
public void afterBegin();
public void beforeCompletion();
public void afterCompletion(boolean b);
}
The way the exceptions are handled affects the way the transactions are managed.
When the container manages the transaction, it is automatically rolled back when a System Exception occurs.This is possible because the container can intercept System Exception. However when an Application Exception occurs, the container does not intercept it and therefore leaves it to the code to roll back using ctx.setRollbackOnly().Be aware that handling exceptions in EJB is different from handling exceptions in Java. The Exception handling best practice tips are:
• If you cannot recover from System Exception let the container handle it.
• If a business rule is violated then throw an application exception.
• Catch the Exceptions in a proper order.
• It is a poor practice to catch java.lang.Exception because this is a big basket, which will catch all the unhandled exceptions. It is shown in the above diagrams for illustration purpose only. You should avoid this because if you add a new piece of code, which throws a new, checked exception, then the compiler won’t pickit up.
Transaction 2 has changed a row, but has not committed the changes. Transaction 1 reads the uncommitted data but his view of the data may be wrong if Transaction 2 rolls back his changes and updates his own changes to the database.
Transaction A begins.
UPDATE employee SET salary = 31650
WHERE empno = '000090'
Transaction B begins.
SELECT * FROM employee
(Transaction B sees data updated by transaction A. Those updates have not yet been committed.)
Read Committed (Non-repeatable reads)
if Transcation T1 reads a row and Transcation T2 changes the same row, when T1 rereads and sees the changes made by T2.Then this is Non - Repeatable Read
ransaction A begins.
SELECT * FROM employee
WHERE empno = '000090'
Transaction B begins.
UPDATE employee SET salary = 30100
WHERE empno = '000090'
(Transaction B updates rows viewed by transaction A before transaction A commits.) If Transaction A issues the same SELECT statement, the results will be different.
Repeatable reads (phantom reads)
If Transcation T1 retrieves a bunch of rows.Transcation T2 inserts a row,T1 rereads the query and if T1 see the additional row, it is a ghost row to T1 then this is called as Phantom Read
Transaction A begins.
SELECT * FROM employee
WHERE salary > 30000
Transaction B begins.
INSERT INTO employee
(empno, firstnme, midinit,
lastname, job,
salary) VALUES ('000350', 'NICK',
'A','GREEN','LEGAL COUNSEL',35000)
Transaction B inserts a row that would satisfy the query in Transaction A if it were issued again.
Pessimistic Locking & Optimistic Locking
In pessimistic locking transaction locks the record as soon as it selects the row to update. While in optimistic locking it is only locked when the actual updating takes place.
Select name from emp where eno=1 for update; (Pessimistic)
Update emp set eno=’xxx’ where eno=1; (Optimistic)
Shared Lock
It permits other transaction to read the locked data but prevent be transaction from modifying the data.
Update Lock
Update lock prevents any other transaction to update the data. When a transaction tried to update data update lock converts to an exclusive lock.
Read Lock
A read lock is lock placed on a resource that is being read or accessed by a transaction. Read lock prevents other transaction to read or update the data which is locked be a read lock.
Exclusive Lock
A transaction places an exclusive lock on data when it is modifying the data. The lock prevents other transaction from reading or updating the locked data. The data remains locked until the transaction is committed or rolled back.
How do you rollback a container managed transaction in EJB?
SessionSynchronization
public class MyBean implements SessionBean, SessionSynchronization{
public int oldVal ; public int val ;
public void ejbCreate(int val) throws CreateException {
this.val=val;
this.oldVal=val;
}
public void afterBegin() { this.oldVal = this.val ;}
public void beforeCompletion(){};
public void afterCompletion(boolean b) { if (b == false) this.val = this.oldVal ; }
.......................................
}
public interface javax.ejb.SessionSynchronization {
public void afterBegin();
public void beforeCompletion();
public void afterCompletion(boolean b);
}
The way the exceptions are handled affects the way the transactions are managed.
When the container manages the transaction, it is automatically rolled back when a System Exception occurs.This is possible because the container can intercept System Exception. However when an Application Exception occurs, the container does not intercept it and therefore leaves it to the code to roll back using ctx.setRollbackOnly().Be aware that handling exceptions in EJB is different from handling exceptions in Java. The Exception handling best practice tips are:
• If you cannot recover from System Exception let the container handle it.
• If a business rule is violated then throw an application exception.
• Catch the Exceptions in a proper order.
• It is a poor practice to catch java.lang.Exception because this is a big basket, which will catch all the unhandled exceptions. It is shown in the above diagrams for illustration purpose only. You should avoid this because if you add a new piece of code, which throws a new, checked exception, then the compiler won’t pickit up.