On Wed, Dec 2, 2015 at 11:49 AM, Tim Ward t...@telensa.com [firebird-support] <firebird-support@yahoogroups.com> wrote:
> > > Yes I do know it's not a real deadlock, I was using the word because I > knew it would be understood and because, I'm pretty sure?, I've seen it > in one of the relevant error messages. > This is really ancient history, but the reason that update conflicts are reported as deadlocks is rooted in the early dark ages of computing, say around 1981. DEC, to its distress, found itself developing two relational databases, one a relational layer on a CODASYL system, and one relational from the ground up using multi-generational concurrency control (created by Jim Starkey). Management decreed that the two systems be compatible shared libraries. Change a link and your application goes from using one to using the other without changes. That meant compatible everything but ODS - system tables, api, and error codes. The solution for error codes was to agree on major error codes that an application could receive and respond to, with the possibility of minor codes to for system specific behavior. Since the solution to an update conflict (not a possibility in the lock-based traditional implementation) is the same as the resolution of a deadlock - rollback and try again - it was lumped under deadlock. When Jim created InterBase, he used the same interfaces in hopes of gaining market share from VAX/RDBMS users who wanted a compatible interface on other hardware. Alas, by that time anyone still using VAXen was so addicted to DEC that they wouldn't consider other hardware let alone foreign software. Cheers, Ann
