Two reasons. One was that Cognos had their own "optimistic concurrency
control" which unstable dbkeys yanked out the rug beneath. The other is
that "consistency mode" murders concurrency, which is why they developed
the optimistic concurrency control for other database systems in the
first place.
In general, transaction consistency mode was a complete crock, but
necessary to compete against database systems with a serializable mode
that suffered horribly if turned on. Thus lead to the numerous relaxes
concurrency modes united by the common factor of not working.
There is a very good reason that multi-version concurrency control won
out big time (Wikipedia lists 80+ database systems with MVCC).
Interbase was the second.
On 5/19/2022 2:35 PM, Leyne, Sean wrote:
-----Original Message-----
From: Paul Beach <pbe...@mail.ibphoenix.com>
Sent: May 19, 2022 12:10 PM
It maintains all the rdb$db_key values for the length of a connection - i.e.
they are not allowed to change. An internal transaction gets started for this.
It was introduced to support Cognos' Powerhouse 4GL product which made
extensive use of db_keys.
Obviously it can have issues re. garbage collection...
That is already supported by "snapshot" (isc_tpb_consistency) transactions, no?
If not, how is it different, aside from the connection vs. transaction level?
Sean
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
--
Jim Starkey, AmorphousDB, LLC
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
