Optimistic concurrency (with essential corrections)Optimistic concurrency rests on somewhat wobbly foundations – the presumption that no user will ever be blocked by another user. Which is usually true for single-user solutions while multi-user solutions require a slight correction to this logic. Put another way: with optimistic concurrency we assume that a particular row will only be modified by one user at any given time, and being fully optimistic we do nothing to prevent different users from trying to modify the same row.
(I must admit that the subject of this post has been discussed pretty much everywhere up to the point of almost being disgusting, but I’ve had this sample laying around for a while and now I’ve decided on moving it somewhere else rather than permanently removing it from my disk.)
Of course not doing anything to prevent what seems quite probable is not optimism – it’s stupidity. On the other hand doing too much (like introducing a sophisticated row-locking mechanism) is also hardly a good idea, especially since elementary cuncurrency management mechanisms already are part of the platform. Basically, what the client application really needs to know before attempting a data modification is: