(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
