What do you understand by the terms optimistic locking versus pessimistic locking?

Q. What do you understand by the terms optimistic locking versus pessimistic locking?

A. Optimistic locking means a specific record in the database table is open for all users/sessions. Optimistic locking uses a strategy where you read a record, make a note of the version number and check that the version number hasn't changed before you write the record back. When you write the record back, you filter the update on the version to make sure that it hasn't been updated between when you check the version and write the record to the disk. If the record is dirty (i.e. different version to yours) you abort the transaction and the user can re-start it.

You could also use other strategies like checking  the timestamp or all the modified fields (this is useful for legacy tables that don't have version number or timestamp column). Note: The strategy to compare version numbers and timestamp will work well with detached hibernate objects as well. Hibernate will  automatically manage the version numbers. 

In Hibernate, you can use either long number or Date for versioning 

?

1 2	@Version private long id;

or 

?

1 2	@Version private Date version;

and mark 

?

1 2 3 4 5 6

@Entity @org.hibernate.annotations.Entity(selectBeforeUpdate = true, optimisticLock=OptimisticLockType.VERSION) @Table(name = "tbl_employee") public class Employee extends MyAppDomainObject implements Serializable {     ..... }

if you have a legacy table that does not have a version or timestamp column, then use either 

?

1 2 3 4 5 6

@Entity @org.hibernate.annotations.Entity(selectBeforeUpdate = true, optimisticLock=OptimisticLockType.ALL) @Table(name = "tbl_employee") public class Employee extends MyAppDomainObject implements Serializable {     ..... }

for all fields and 

?

1 2 3 4 5 6

@Entity @org.hibernate.annotations.Entity(selectBeforeUpdate = true, optimisticLock=OptimisticLockType.DIRTY) @Table(name = "tbl_employee") public class Employee extends MyAppDomainObject implements Serializable {     ..... }

for dirty fileds only. 

Pessimistic locking means a specific record in the database table is open for read/write only for that current session. The other session users can not edit the same because you lock the record for your exclusive use until you have finished with it. It has much better integrity than optimistic locking, but requires you to be careful with your application design to avoid deadlocks. In pessimistic locking, appropriate transaction isolation levels need to be set, so that the records can be locked at different levels. The general isolation levels are

• Read uncommitted isolation
• Read committed isolation
• Repeatable read isolation
• Serializable isolation

It can be dangerous to use "read uncommitted isolation" as it uses one transaction’s uncommitted changes in a different transaction. The "Serializable isolation"  is used to protect phantom reads, phantom reads are not usually problematic, and this isolation level tends to scale very poorly. So, if you are using pessimistic locking, then read commited and repeatable reads are the most common ones.