I have a general "how to approach this" question about a particular use of hibernate.

I'm working on a web-application with Hibernate and seeing a lot of lock contention, which is causing both performance problems and occasional deadlocks. Part of the problem (the part that I'd like help on) is that Hibernate is always using SELECT...FOR UPDATE, which holds certain kinds of lock in PostgreSQL. It happens that the our application maintains a clear separation between operations which modify the database, and operations which do not. This makes the use of SELECT...FOR UPDATE for the [far] more frequent "change nothing" operations, and the resulting lock contention, particularly inconvenient.

What I'd like to do is:

- have operations which do modify objects continue to use SELECT...FOR UPDATE

- have operations which do not modify objects just use a plain SELECT.

I'm not looking to depend upon Hibernate to determine which case is which; I'll tell it; I'm interested in knowing how to tell it, if this is in fact possible.

It seems that one, rather crude, way of doing this is with a second level cache, but this works per-class, not per-transaction. I do want to be able to operate on the same types (indeed the same instances/rows) from the same application, but have some transactions use SELECT and some use SELECT...FOR UPDATE.

Is this possible?

[b]Hibernate version: 3.2.4[/b]

[b]Name and version of the database you are using: PostgreSQL 7.4.7[/b]