I've been reading quite a bit about concurrency, transactions, and versioning. I'll need to use these concepts for a busy calendar application I'm working on. I'm pretty sure I know what needs to be done. However, there is one item I'm not quite sure on:

If my application is the only entity to access the database, is it enough to use optimistic concurrency via the Version tag? Or do I need to combine that with pessimistic locking (LockMode.Upgrade) to bypass cache and row level lock my table just before an update?

It seems to me, to be absolutely sure I don't get any collisions, I'll need to row level lock the database table. However, I see places where the docs suggest pessimistic locking is rarely needed?

Anyone building a similar application where concurrency issues are probable? What did you do?

If the app is going to have a relatively low number of users, the easiest solution is to only put one connection in your connection pool. That will ensure zero collisions.

If there will be a fairly high number of concurrent users and you neeed more than one connection, then yes, you need upgrade locks. An alternative would be to have a single data access thread that all application threads talk to, but that's basically the same thing as a single connection, so there's no benefit in doing that.

Thanks for the note.

Still seems wierd. I don't see why anyone building a mutli-user web application could ever just use hibernate versioning.

I'm using Spring and I just created a test case to verify versioning is working correctly. One thing I'm perplexed about is right after I attempt to update the database with a stale database object, the logs show the flush mode is being changed to Never:



So from this point on, In my test, I can no longer write to the database. That is true even if I do an explicit reload on my object. What is the accpeted way to deal with this?