Hibernate transaction

 

(captured from a very good Hibernate Book, copyright belongs to the author)

 

First type lost

First transaction’s rollback overwrite second transaction’s update on same record

 

Second type lost

First transaction’s commit overwrite second transaction’s update on the same record

 

Dirty Read

Read uncommitted data

 

Phantom Read

Second read get extra record

 

Non-repeatable read

Two read return’s different result.

 (All above issues is due to someone did something in the middle of a transaction, I hate being interupted)

 

If one session has exception, need close it, not resue again.

  

Database Lock types

share

exclusive

update

 

Database lock applied ranges

1. database

2. table

3. area

5. page

6. record

...

 

 Transaction optimize

1. short transaction

2. reduce the transaction isolation level if consistency is not strict

 

Database Lock

1. Optimistic lock

• Version field goes after the definition of ID
• timestamp can also do the job
• version is better than timestamp, because system only check to second, actually transaction might happen within 1 second.

2. Pessmistic lock

• application lock through database exclusive lock
• database add extra column as locker