Hi again Jim, and thanks for your replies - it's interesting reading about the
history of MVCC inter alia - see below.
Your answers bring up a couple of questions though.
> One day I was driving down Route 3 in Manchester, New Hampshire, that
> rather than keeping multiple page images, I coul
For what it's worth, David Reed's dissertation was on a
non-transactional distributed directory system. Bernstein and Goodman's
book "proved" that MVCC was serializable, which it most definitely was not.
Bernstein and Goodman also worked on a research project called SDD-1 to
see if it was pos
> https://en.wikipedia.org/wiki/Multiversion_concurrency_control#History
Szía Attila, és köszi!
Hi Attila, and thanks!
Pól...
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
ladó: Pól Ua L. via Firebird-devel
[mailto:firebird-devel@lists.sourceforge.net]
Küldve: 2022. május 26., csütörtök 9:11
Címzett: For discussion among Firebird Developers
Másolatot kap: Pól Ua L.
Tárgy: Re: [Firebird-devel] isc_dpb_dbkey_scope
Hi Jim,
great to see that you're still keeping y
.
Tárgy: Re: [Firebird-devel] isc_dpb_dbkey_scope
Hi Jim,
great to see that you're still keeping your finger in the Firebird pie!
> There is a very good reason that multi-version concurrency control won
> out big time (Wikipedia lists 80+ database systems with MVCC).
> Interbase
Hi Jim,
great to see that you're still keeping your finger in the Firebird pie!
> 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.
Just as a matter of historical interest, which w
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 pl
> -Original Message-
> From: Jim Starkey
> Sent: May 19, 2022 3:08 PM
> They have nothing to do with each other. A transaction isc_tpd_consistency
> keeps two phase table locks to make transactions serializable. An
> attachment with isc_dpb_dbkey_scope is about preserving dbkeys acros
They have nothing to do with each other. A transaction
isc_tpd_consistency keeps two phase table locks to make transactions
serializable. An attachment with isc_dpb_dbkey_scope is about
preserving dbkeys across transactions within an attachment.
On 5/19/2022 2:35 PM, Leyne, Sean wrote:
--
> -Original Message-
> From: Paul Beach
> 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 pr
>How is subj supposed to work? I see that it forces engine to start a
> transaction and that's all.
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'
If I remember correctly, it starts a transaction to inhibit garbage
collection for the duration of the attachment so any dbkeys returned
remain valid across succeeding transactions on the attachment.
On 5/19/2022 11:38 AM, Dimitry Sibiryakov wrote:
Hello All.
How is subj supposed to work? I
Hello All.
How is subj supposed to work? I see that it forces engine to start a
transaction and that's all.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
13 matches
Mail list logo
