I am writing a application that uses hibernate and I can't see how to work around needing pessimistic locking that will last beyond one session. My understanding is you can't do multi session pessimisitic locking in hibernate, am I right? I know there is are several people who want more complex locking behavior for tasks where it isn't needed but I'm pretty sure this isn't the case.

Here is what I've got. Hibernate is being used to persist data objects that respond to various messages. (Think complex state machine). Responding to each message could take a short amount of time. Long enough that other messages for that object could come in during that time. And sometimes I might need to close the session during that time. My understanding is that

I can not have one object respond two messages at a time. Responding to a message has side effects that can not be rolled back and that will affect how future messages are responded to. I need some sort of concurrency control.

If I was doing this all in memory what I would do would be have a lock per data object, get the lock when responding to the message, and release the lock when done. Obvious, simple, works. But having everything in memory is not an option for many reasons (scalability and reliability just being an obvious two.)

The only think I can think to do is have an "in use" flag as part of the object representation in the database and when I first get an object get it for update and then set that flag to true if it is false. That seems ugly and requires some way to know when the flag was set to false later on so any waiting requests can wake up and do their thing? Is there some solution I'm totally missing?

Thanks,
Anthony

That is correct, Hibernate does not offer the out-of-box option to shot yourself in the foot ;) (Well, it does, but not this one.)

Its quite trivial to implement your own lock manager _using_ Hibernate though. A good guide (although not complete) is in Martin Fowlers patterns collections as "pessimistic offline lock". Make sure you really understand the performance implications of introducing this bottleneck to your application.

Here's another crazy thought:
What if you manage the JDBC connection and use multiple Sessions that never commit (intent of not committing being to not release DB locks)?

Please keep in mind that I have never used Hibernate pessimistic locking support before (except the normal short-lived, explicit transaction management to keep my bussiness transactions consistent), so I dunno if this would work at all.


This is what I mean:
- get yourself a JDBC connection (ie. user managed connection, not hibernate managed).
- create a Session on the connection (ie. use the SessionFactory.createSession(Connection) method)
- set the session flushmode to never (session.setFlushMode(FlushMode.NEVER))
- use whatever HB mechanism you would normally use to take your pessimistic lock (this is the part I'm pretty vague on, having never used this stuff myself)
- do stuff with the session (pessimistic lock is in effect)
- close the session (this shouldn't commit, because of the FlushMode setting, right?)

- do your other stuff, possibly including returning from a HTTP invocation (pessimistic lock is still in effect)

- create a Session on the same connection as before (the intent here being that this Connection still wouldn't have had commit(), rollback() or close() called on it)
- do more stuff on the connection (pessimistic lock is still in effect)
- close the second Session and commit the original Connection (pessimistic lock should then be released)


I couldn't imagine where I would ever use this myself, but it would work(*) wouldn't it?

Any traps in there? (beyond the obvious possibility (probability?) of bringing your entire system to a screaming halt because you didn't release a lock on an important piece of data)

(*) Keeping in mind that by work, I mean keep pessimistic locks across multiple hibernate Sessions.

Your DBA will slap your fingers if you don't release the JDBC connection as quickly as possible. He will very likely cut your hand off (and your users as well, if they see how it performs) if you hold the connection open for 10 minutes.

Pfft, in my system (Ingres, using the enterprise connection manager drivers) connections never seem to time out (I dunno, don't ask me - it's Ingres) and our lock timeout and lock-wait timeout are set to never as well. So if we did this, our app would be locked-up forever or until reboot time, whichever comes first.

10 minutes. Pfft. DB timeouts are for fraidy-cat developers who are afraid of taking responsibility for their decisions ;)

But anyway, it'd keep the locks open wouldn't it? (I thought Session.close() might stomp the whole idea by committing the transaction or something)

Locks in a typical pessimistic locking system in a database have to be held until the end of the database transaction. The end of a single database transaction should be the end of a single database connection, and both should be kept as short as possible in a highly concurrent OLTP scenario.