Hi All,

We have used LLBLGen successfully for a couple of projects in the company I work for. A new project is about to begin and a "not-implemented before" requirement came to light and that is Pessimistic Locking!

Our environment is: ASP.NET 2.0 LLBLGen 2.6 - Adapter Oracle or SqlServer (not yet final)

I have been reading about the IConcurrencyPredicateFactory and tried to see how to use it. Although I believe I can understand its use in an Optimistic Concurrency scenario, I fail to see how to use it in a Pessimistic concurrency scenario like the one I am facing.

I searched the forum extensively but I couldn't find any relevant threads. Is there an example or any links/leads as to how to use this?

Chris

PS. I have already considered that Pessimistic locking is not the most suitable model for the Web but my requirement simply cannot change. So please don't debate on this!

Please check this out: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=10960

If you want to use locks, then simply start a transaction when ever you need a lock, and the database will place the lock for you. ref: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=10828

Pessimistic locking is not going to work in the end, as the code setting the locks is outside the DB. You shouldn't want to set locks on rows explicitly for the sake of concurrency, as it will block all other code accessing that DB. Indeed, as Walaa said, look into other means of implicit locking through transactions and isolation levels. Oracle already doesn't need locking as it supports MVCC, sqlserver has snapshot isolation which is basicly the same thing.

Hi All,

Thank you for the links and for your thoughts on this.

The real reason we need Pessimistic locking is that we will have composite entities (ie main entities with their relations) being managed/edited for long periods of time (a customer with her accounts for example). A user might edit an entity continuously for one hour!

I wasn't planning on using row level locking at the database level because the overhead of spanning a transaction across multiple requests is too big and I am not sure I can implement it either!

I will probably build a locking service that either marks an entity as locked by adding a flag column or by keeping locks in separate tables. In any case, locks will be persisted but not managed by the database. I will probably use Optimistic locking for the Locking Service I am mostly thinking of a classic checkin/checkout CMS like scenario.

I will have to build a number of workarounds to mitigate the stateless nature of the web, I know it and I am willing to do implement it.

In any case, I am off to build a prototype and see what happens.

Thanks again!

Chris

I am mostly thinking of a classic checkin/checkout CMS like scenario.

Same thought came to me

Good luck implementing it.