Manually locking of DB necessary even if I use Hibernate/Postgresql/JDBC?

Question

Sorry to ask this in case it has been answered before, but I heard (from a potential other noob) that Hibernate has/had some kind of connection pool manager that also handles locking of the database. Now I read this was abolished in Hibernate 3 so I, as a noob, am very confused what to use.

I have a Postgresql db with multiple clients that each use max. one db connection at any given time. I use JDBC but want to move to Hibernate.

So in case two concurrent update operations occur, I don't know if this is handled by the DBMS correctly. I thought about locking a db table manually in case someone operates on it, but there must be a better way.

I only operate with simple, single sql-statements, sometimes prepared statements. No big updates, just single line updates.

Do you have any idea how this, generally, is to be solved? Is this even a problem?

Answer 1

This is too general for a truly useful answer, and I should really just close-vote it. But I'll try to help.

The connection pool has nothing to do with locking. The two are unrelated topics.

I think you're vaguely trying to refer to the optimistic concurrency control in Hibernate. This is an alternative strategy to normal row locking, with a different set of advantages and disadvantages.

See the Hibernate documentation for more information, and the wikipedia article on optimistic concurrency control.

I also wrote a recent blog entry on this topic that may be useful.

Above all else, though, there's no substitute for actually understanding concurrency in the application and database. I very strongly recommend reading the PostgreSQL documentation chapter on concurrency control in detail.