From what i understand about concurrency in hibernate is this:
You use read committed mode in conjunction with versioning.
So assume you start a session and make your query.
The returned objects, representing your query result, will be only accessible within you persistence context(session).
When you want to update and commit your changes, hibernate will obtain a read and write lock from the database; compare the version between
the objects in your persistence context and the database. If the objects have the same version, the update and commit work
otherwise an exception is raised by hibernate - you notify the user that he/she has been working on stale data and they re-do their work.
Is this the right idea?

Now, what kind of undermined my confidence of my understanding on how to use hibernate is the following:
I'm reading a book called Java Persistence with Hibernate. That book is a recommended read by the hibernate community.
In that book it is explained that you might want to obtain additional isolation guarantees with pessimistic locking.
In particular, an example(chapter 10.2.3, Explicit pessimistic locking) is provided:
Assume you load an object and(placeHolder) then query the database from a scalar value. Then update that object using that scalar value.
At time placeHolder, another session has changed the first object's row in the database. That would mean you are working on stale data.
But in my description, in the first paragraph, the update will fail anyway because the version mismatch would indicate stale data.

So can anyone please share their thoughts on all this?
Thanks.

when using pessimistic locks, we rely on the Database locks. So you most likely want to read about transaction isolation levels, they are implemented at database level:
http://en.wikipedia.org/wiki/Transaction_isolation

In short, a pessimistic lock will acquire the lock on the records you're reading as soon as you read them, and so if another thread is going to change one of these it's blocked until you're done with your current transaction: so changes are sequential and no issues happen. This strategy is safe but will obviously degrade performance, and in some cases you want to manage it differently.

So using optimistic locking is a known alternative, usually a bit cumbersome to implement so Hibernate provides native helpers for it.

Up to you which one to choose, no one is mandatory.