Using pessimistic locking in DevForce entities and transaction UIs

Michael, 

DevForce does not inherently support pessimistic concurrency, which is why our tutorials address only optimistic concurrency. 

DevForce is designed to support highly-scalable, high-performing applications.  Database connections are opened and closed as needed, but always for short durations.  This means that a single PM.GetEntities call opens a connection, fetches data, and closes the connection.  A single PM.SaveChanges call opens a connection, persists data, and then closes the connection.  This is true whether the application is client-server or uses a Business Object Server.  Since connections are always short-lived, any locks held are also short-lived, and there is no way to issue a lock spanning the boundaries of an individual get or save. 

We always advise that our customers not use pessimistic concurrency, since we believe optimistic concurrency is the better approach and can be used with most, if not all, applications.  For a kind of “checkout” pattern where you want a user to grab something and hold onto it until done, you have several options other than database locks.  One would be to use a flag of some sort on the record itself which could indicate availability/in use.  Another option might be to use an additional table that tracks “checkouts”.  I’m sure there are other options too, but what these have in common is that they do not rely on an open connection and database locks, but instead make the “locking” the responsibility of the application. 

Please let me know if you need any more information.  If so, I can try to give you a more detailed explanation or get you in touch with one of our architectural gurus.