Pessimistic and optimistic locking

Pessimistic and optimistic locking

There are two different ways transactional locking is done.
Pessimistic and optimistic locking and that is how transactional isolation is achieved.

When we do pessimistic locking, we lock the resource when it is accessed the very first time and the lock is not released till the time, transaction is finished i.e, either committed or rolled back. The disadvantages of this apporach will be that the resource will be locked and no other process can access this resource till the lock is released. This can result in lock contention and the other processing trying to access the lock will be either delayed or their transaction will be rolled back.

WIth the optimistic locking, the resouece is not locked the way it is done in the case of pessimistic locking. The time the resource is first accessed, the state of the resource is saved. And when it is the time for the resource to be updated, the current state and the saved state is matched. Is their is any difference, the transaction is rolled back. This way the other transactions are not rolled.

This is the theory, but I am not sure how it works in reality. Sounds to me to be a complex way to achieve transaction isloation and what if this resource in question, is accessed frequently. Will this not result in performance bottleneck?

Spring framework

These days I am reading the book. Spring: A Developer's notebook. A real fundu book. Just finished the basic understanding part and now reading how to implement MVC based on the spring framework.

What surprises me is the ease with which you can write code with Spring. So simple, yet beautiful and powerful.

Spring and EJB

Why Spring makes sense?

1. Spring keeps the framework out of the code. i.e, no framework-specific requirements on objects.

2. Spring is simpler than EJB mostly because they take a more POJO-based approach,

3. Code is not heavily dependent on the container so unit testing is easy.
You can even run some integration tests using a Spring container but not a heavier J2EE app server–unlike any app server, a Spring container takes very little time to start up.