Optimistic database locking

BOARD18 code has some limited previsions for preventing database damage.

Unfortunately these provisions only consist of optimistic database locking. Optimistic database locking involves checking if the record was updated by some other session after you read the record and before you commit the update transaction. This works best when it is unlikely that a lot of users will be accessing and updating the record at the same time. EG: when being used for play by email games.

The other option, pessimistic database locking, is when a session takes an exclusive lock on the table or on a specific record so that no other session can start modifying that record. A pessimistic lock should be used when a lot of sessions may be trying to access the same record at the same time. EG: a "live" playing session. And, for example, players having 2 windows open at the same time can make the problem worse.

Pessimistic locking provides better integrity on the data. However management of the lock is harder and, if your application fails to manage that, your session may encounter deadlocks. Deadlocks are very hard to debug.

Converting BOARD18 to pessimistic locking is not a task that I am anxious to attempt at this time!