Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

core error - bus dumped


devel / comp.databases.theory / Re: Checkpoint & Consolidated Doc

SubjectAuthor
* Stored procedure structure in RDBMS using Lock Manager for transaction isolationDaniel Loth
`* Re: Stored procedure structure in RDBMS using Lock Manager for transaction isolaDerek Ignatius Asirvadem
 `* Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
  `* Re: Stored procedure structure in RDBMS using Lock Manager forDaniel Loth
   `* Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
    +* Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
    |`* Re: Stored procedure structure in RDBMS using Lock Manager for transaction isolaDaniel Loth
    | `* Re: Stored procedure structure in RDBMS using Lock Manager for transaction isolaDerek Ignatius Asirvadem
    |  `* Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
    |   `* Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
    |    `- Re: Stored procedure structure in RDBMS using Lock Manager forDaniel Loth
    `* Re: Stored procedure structure in RDBMS using Lock Manager forNicola
     +* Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
     |`* Re: Stored procedure structure in RDBMS using Lock Manager forNicola
     | `- Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
     `* Re: Stored procedure structure in RDBMS using Lock Manager for transaction isolaDerek Ignatius Asirvadem
      `* Re: Stored procedure structure in RDBMS using Lock Manager forNicola
       `* Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
        `* Re: Stored procedure structure in RDBMS using Lock Manager forNicola
         `* Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
          `* Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
           `* Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
            `* Re: Stored procedure structure in RDBMS using Lock Manager forDerek Ignatius Asirvadem
             `* Checkpoint & Consolidated DocDerek Ignatius Asirvadem
              +- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
              `* Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
               `* Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                `* Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                 `* Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                  +- Re: Checkpoint & Consolidated DocDaniel Loth
                  +- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                  +- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                  +- Re: Checkpoint & Consolidated DocDaniel Loth
                  +* Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                  |+* Re: Checkpoint & Consolidated DocNicola
                  ||+- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                  ||+- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                  ||+- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                  ||+- Re: Checkpoint & Consolidated DocDaniel Loth
                  ||`- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                  |`- Science vs Pseudo-Science; Modern "Science"Derek Ignatius Asirvadem
                  +- Re: Checkpoint & Consolidated DocDaniel Loth
                  +- CorrectionDerek Ignatius Asirvadem
                  +* Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                  |`* Re: Checkpoint & Consolidated DocNicola
                  | `- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                  `* Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                   `* Re: Checkpoint & Consolidated DocNicola
                    +* Re: Checkpoint & Consolidated DocNicola
                    |`* Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                    | `* Re: Checkpoint & Consolidated DocNicola
                    |  `- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                    `* Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                     `* Re: Checkpoint & Consolidated DocNicola
                      +* Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                      |`* Re: Checkpoint & Consolidated DocNicola
                      | +* Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                      | |+* Re: Checkpoint & Consolidated DocNicola
                      | ||+- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                      | ||`- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                      | |`* Re: Checkpoint & Consolidated DocNicola
                      | | `- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                      | `- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                      +- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                      +- Re: Checkpoint & Consolidated DocDerek Ignatius Asirvadem
                      `* Questions from the AsylumDerek Ignatius Asirvadem
                       `* Re: Questions from the AsylumNicola
                        `* More Demanding Questions from the AsylumDerek Ignatius Asirvadem
                         `* Re: More Demanding Questions from the AsylumNicola
                          +* Re: More Demanding Questions from the AsylumDerek Ignatius Asirvadem
                          |+* Re: More Demanding Questions from the AsylumNicola
                          ||`- More Questions from the AsylumDerek Ignatius Asirvadem
                          |`- The Larger Problem • Collective InsanityDerek Ignatius Asirvadem
                          `* Re: More Demanding Questions from the AsylumDerek Ignatius Asirvadem
                           +- Re: More Demanding Questions from the AsylumNicola
                           `* Re: More Demanding Questions from the AsylumDerek Ignatius Asirvadem
                            `* Re: More Demanding Questions from the AsylumNicola
                             +- Re: More Demanding Questions from the AsylumDerek Ignatius Asirvadem
                             +- Discourse on Insanity, Academia, MV-non-CCDerek Ignatius Asirvadem
                             +- Re: Discourse on Insanity, Academia, MV-non-CCDerek Ignatius Asirvadem
                             `* Transaction Sanity doc UpdateDerek Ignatius Asirvadem
                              `* Re: Transaction Sanity doc UpdateNicola
                               +- Re: Transaction Sanity doc UpdateDerek Ignatius Asirvadem
                               `- Serialisation ??? Schedules ???Derek Ignatius Asirvadem

Pages:1234
Re: Checkpoint & Consolidated Doc

<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=184&group=comp.databases.theory#184

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:620a:126e:: with SMTP id b14mr13412696qkl.36.1625483852497;
Mon, 05 Jul 2021 04:17:32 -0700 (PDT)
X-Received: by 2002:aca:b609:: with SMTP id g9mr9758251oif.141.1625483852311;
Mon, 05 Jul 2021 04:17:32 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Mon, 5 Jul 2021 04:17:32 -0700 (PDT)
In-Reply-To: <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.42; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.42
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Mon, 05 Jul 2021 11:17:32 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Derek Ignatius Asirv - Mon, 5 Jul 2021 11:17 UTC

Dan, Nicola

This week is super-busy for me, I will be offline.

I endeavoured to clean things up, so that you can proceed unhindered, and to restate the particular steps required to progress this thread to closure.
__ identify two more Concurrency problems that need to be prevented in an OLTP context.
__ then, next week, I will provide the one solution that prevents both.

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=185&group=comp.databases.theory#185

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a0c:b38c:: with SMTP id t12mr12459929qve.44.1625486402431;
Mon, 05 Jul 2021 05:00:02 -0700 (PDT)
X-Received: by 2002:aca:fc57:: with SMTP id a84mr10013843oii.50.1625486402241;
Mon, 05 Jul 2021 05:00:02 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Mon, 5 Jul 2021 05:00:02 -0700 (PDT)
In-Reply-To: <ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.42; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.42
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Mon, 05 Jul 2021 12:00:02 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Mon, 5 Jul 2021 12:00 UTC

Dan, Nicola

This week is super-busy for me, I will be offline.

I have endeavoured to clean things up, so that you can proceed unhindered. I have also provided a doc that illustrates the problems in *Full Context*, hopefully to avoid dealing with fragments out of context. To restate the particular steps required to progress this thread to closure:
__ identify two more Concurrency problems that can't be prevented by SQL or ACID Transactions, that need to be prevented in an OLTP context (items that are well-known since 1965)
__ then, next week, I will provide the one solution that prevents both.

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=188&group=comp.databases.theory#188

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:620a:ceb:: with SMTP id c11mr4145359qkj.331.1627043761603;
Fri, 23 Jul 2021 05:36:01 -0700 (PDT)
X-Received: by 2002:aca:1017:: with SMTP id 23mr8406456oiq.141.1627043761359;
Fri, 23 Jul 2021 05:36:01 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Fri, 23 Jul 2021 05:36:01 -0700 (PDT)
In-Reply-To: <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.42; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.42
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Fri, 23 Jul 2021 12:36:01 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Fri, 23 Jul 2021 12:36 UTC

Dan, Nicola

> On Monday, 5 July 2021 at 22:00:03 UTC+10, Derek Ignatius Asirvadem wrote:

I am back, please forgive the delay. It is madness over here. Worse lockdown conditions in two years. Nothing like a plandemic and a fear-mongering media, slaves of Big Pharma.

Two weeks and no activity. Come on, guys, this thing needs interaction. Proposal. Question. What if.

We have left the me, me, me-centred toilet, we have stopped looking in the mirror and repeating "I am a chick magnet". We have entered the big bad world of reality, where conflicts are no big deal because we are social, civilised people, and we have civilised ways resolving conflicts. No need to stay at home and clutch the obsolete private version of the database.

OLTP (learned some, more to go)
ACID (learned somne, more to go)
Transactions (good start)
SQL

We know about Phantoms; Anomalies; Deadlocks. We can dismiss "Serialisation Anomimimilies" as the particularly stupid way that people who think they have invented the wheel collide with the reality of the road.

What else could go wrong ?

What precisely does [D]urable mean ?

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=189&group=comp.databases.theory#189

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:620a:903:: with SMTP id v3mr8446780qkv.235.1627120125921;
Sat, 24 Jul 2021 02:48:45 -0700 (PDT)
X-Received: by 2002:a54:4895:: with SMTP id r21mr5437587oic.30.1627120125577;
Sat, 24 Jul 2021 02:48:45 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Sat, 24 Jul 2021 02:48:45 -0700 (PDT)
In-Reply-To: <7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.146; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.146
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Sat, 24 Jul 2021 09:48:45 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Sat, 24 Jul 2021 09:48 UTC

Guys and dolls, lays and germs, boys and girls

> On Friday, 23 July 2021 at 22:36:02 UTC+10, Derek Ignatius Asirvadem wrote:

> Two weeks and no activity. Come on, guys, this thing needs interaction. Proposal. Question. What if.
>
> We know about Phantoms; Anomalies; Deadlocks.

We did, from 1965. There are four categories of error that we know about and have solutoins for, those are two out of four.

The academics found out about it in somewhere in 2002.

> We can dismiss "Serialisation Anomimimilies" as the particularly stupid way that people who think they have invented the wheel collide with the reality of the road.

That is not one of the four categories, it is a unique feature of PissMyselfGross. MySQL and Oracle do not have it. But hey, the academics have written about 100 papers about it, so they think they invented it (in denial of the fact that other MV-non-CC program suites Ingres/Oracle/MySQL had had it for 20 years before they noticed).

> What else could go wrong ?

Two down, two to go.

> What precisely does [D]urable mean ?

>>>>
https://www.ibm.com/docs/en/cics-ts/5.4?topic=processing-acid-properties-transactions

Durability
After a transaction successfully completes, changes to data persist and are not undone, even in the event of a system failure.
<<<<

The OO/ORM/OOP boffins and academics (lazy and vociferously ignorant) think that, oh, the platform or program suite supplies that, we need do nothing. It helps to blow your nose and smell the coffee. Then go outside and socialise with people. Who actually use an online shared database.

It is true that the system failures will be taken care of, by the platform/program suite, to the extent that redundancy; etc has been implemented by the customer. But what about the Transaction itself, is it [D]urable ?

Consider:

Person has a Credit Rating [A] which allows $10,000 overdraft
Person fails to keep agreements re covering their overdraft

Time[ 1 ]
Credit Manager intends to change Credit Rating [D]; $0 overdraft
He is using a GUI, the duration between retrieval & painting the data into the GUI, and the moment he hits the <Save> button in uncontrolled (cannot be controlled). Toilet break; take a phone call; check policy docs; etc.

Time[ 2 ]
Person has a balance of $5,000 DR (overdrawn)
Person phones bank clerk
Checks that he still has Credit Rating [A]
Changes his address
Bank officer is using a GUI, same issues.

Time[ 3 ]
Credit Manager hits <Save>, which COMMITS his changes.
Moves on to next task.

Time[ 4 ]
Bank officer hits <Save>, which COMMITS her changes.

Time[ 5 ]
Person attempts to withdraw $2,000 at the bank
Bank teller checks his account and status.
System states his balance is $5,000 DR (overdrawn), Credit Ratings [A].
Provides $2,000 in cash, new balance $7,000 DR overdrawn.

What the hell happened ? Is that a Durable Transaction ? No way. Not an acceptable system.

This, lays and germs, is known, since 1965, as the
-------------------------
-- Lost Update --
-------------------------
problem. The third of four categories of error, to be handled, in any OLTP system.

Note that the server/program-suite cannot prevent this. Not a genuine OLTP server, let alone one hundred programs cobbled together. Not even an ACID-compliant server, let alone a bunch of programs that implement a strange notion of “transaction”.

The academics not only DON’T KNOW about this, or any other OLTP consideration, when I informed them 11 years ago (during my three years of hard labour at the Hey Presto, the Torrid Manifesto gulag), they did not understand it. The established /If I did not invent it, it does not exist/ syndrome that cripples academics. They had no interest in the solution.

>>>>
Exclusions.

1. We are not arguing about the right or wrong way {all SQL in the GUI; Validate & Exec in the GUI, Xact sp in the database; any other method}. (We will have a resolution at the end.) Feel free to declare what it should be. Discuss.

2. Let’s not have an argument about this one item, because it is laborious, and I have done it to death about 30 times. In most cases, for reasons of simplicity, for an UPDATE, either the fragmented SQL code in the GUI xor the atomic SQL code in the Transaction sp, would UPDATE all attribute columns. So whether it is the Credit Manager changing this, or the bank officer changing that, it is writing all the attribute columns that are held in that client GUI.

The idea in the example above is, the bank officer’s changes over-wrote the Credit Manager’s changes.
<<<<

Doc updated. More detail and a Data Model:

____ https://www.softwaregems.com.au/Documents/Article/Database/Transaction/Transaction%20Sanity.pdf

I have not received any comments about the earlier version (two pages). Please feel free.

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=190&group=comp.databases.theory#190

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ac8:665a:: with SMTP id j26mr7618491qtp.254.1627123669435;
Sat, 24 Jul 2021 03:47:49 -0700 (PDT)
X-Received: by 2002:a05:6830:2316:: with SMTP id u22mr5815279ote.90.1627123669149;
Sat, 24 Jul 2021 03:47:49 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Sat, 24 Jul 2021 03:47:48 -0700 (PDT)
In-Reply-To: <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=193.119.51.108; posting-account=S056qgoAAAASvuIiqcdQPeaQ70w-ZkVa
NNTP-Posting-Host: 193.119.51.108
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: daniel.j...@gmail.com (Daniel Loth)
Injection-Date: Sat, 24 Jul 2021 10:47:49 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Daniel Loth - Sat, 24 Jul 2021 10:47 UTC

Hi Derek,

Welcome back. I'll reply to things you've wrote across both of your emails.

---

> What precisely does [D]urable mean ?

It means that the outcome of the transaction has been successfully committed.
So it has been written to disk (and potentially one or more replica / follower nodes), and won't be lost should the system crash (or the power go out)..

---

> Two down, two to go.

I know one is lost updates, though I see you've addressed it in your email.

I read the PDF you put together years ago: http://www.softwaregems.com.au/Documents/The%20Third%20Manifesto/Transaction%20TTM%20101122.pdf

Now I'm not entirely sure if it's in the same class of problem as anomalies / deadlocks / lost updates, but since you've spoken about sociable behaviour already I'm going to go out on a limb and say 'contention management'.

With proper contention management leading to higher performance, and poor contention management (e.g.: gratuitously acquiring locks needlessly) leading to low performance.

And I suppose the answer to that is 'optimistic locking', which we've discussed.
Optimistic locking being achieved by the retrieve-validate-execute pattern we've also discussed.

---

Regarding the Transaction Sanity document, I read through it when you first shared it two weeks ago.

I'm already reasonably familiar with some of the items described.

For example, I know the bit about 'Client Application (Multiple)' ties in with your Open Architecture document here: http://www.softwaregems.com.au/Documents/Article/Application%20Architecture/Open%20Architecture.pdf

I'm also reasonably across the notion of fully constraining the data using declarative constraints, and the methods that can be used to achieve this (e.g.: enforcing exclusive basetype-subtype using check constraint, as documented here: http://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/Subtype.pdf

The notion of 'ResultSet (multi-statement) Integrity' I'm not so sure about..
That's probably the one concept that I haven't encountered elsewhere in your writing. Or at least I haven't encountered it named as such.

---

Cheers,
Dan

Re: Checkpoint & Consolidated Doc

<8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=191&group=comp.databases.theory#191

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ac8:688b:: with SMTP id m11mr11265642qtq.122.1627216401130;
Sun, 25 Jul 2021 05:33:21 -0700 (PDT)
X-Received: by 2002:a9d:6c1:: with SMTP id 59mr8470430otx.318.1627216400846;
Sun, 25 Jul 2021 05:33:20 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Sun, 25 Jul 2021 05:33:20 -0700 (PDT)
In-Reply-To: <86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.78; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.78
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Sun, 25 Jul 2021 12:33:21 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Sun, 25 Jul 2021 12:33 UTC

> On Saturday, 24 July 2021 at 20:47:50 UTC+10, Daniel Loth wrote:
>
> Welcome back.

Thanks !

> I’ll reply to things you've wrote across both of your emails.

It appears you have read this post:

__ > On Friday, 23 July 2021 at 22:36:02 UTC+10, Derek Ignatius Asirvadem wrote:

but not this post:

__ > On Saturday, 24 July 2021 at 19:48:47 UTC+10, Derek Ignatius Asirvadem wrote:

Also, it may be that you do not have the updated doc (4pages), the earlier version was 2 pages. The Lost Update problem is fully defined with an example Data Model and detailed code.

__ https://www.softwaregems.com.au/Documents/Article/Database/Transaction/Transaction%20Sanity.pdf

> ---
> > What precisely does [D]urable mean ?
> It means that the outcome of the transaction has been successfully committed.
> So it has been written to disk (and potentially one or more replica / follower nodes), and won't be lost should the system crash (or the power go out).

The IBM link I gave for reference:
__ https://www.ibm.com/docs/en/cics-ts/5.4?topic=processing-acid-properties-transactions
states:
__”After a Transaction successfully completes, changes to data persist and are not undone, even in the event of a system failure.”

1. There is no mention of COMMIT (although we know that “completes” means successful COMMIT).
2. The declaration is quite different, in that Durable means the Transaction persists, rather than about system failure, or how that i accomplished.

So did the example Transaction persist, or was it wiped out by a similar Transaction ?

- by your definition of [D]urable, the Transaction is fine, the Lost Update is unknown (happens all the time, and people are ignorant that it happens)..

- by the IBM definition, the Transaction failed, it did not persist, it is not [D]urable. The Lost Update is known.

But how is it prevented ?

> > Two down, two to go.
> I know one is lost updates, though I see you've addressed it in your email.

Correct.

> I read the PDF you put together years ago: http://www.softwaregems.com.au/Documents/The%20Third%20Manifesto/Transaction%20TTM%20101122.pdf

Crikey. A bit of context is demanded.

>>>>
Eleven years ago, I had just come out of pure high-end consulting (ignorance of the madness that was happening in the 95% of the market), and entered into helping people outside my ambit. I had not had the pleasure of reading the literature (no need because Cincom/TOTAL and then Sybase/SQL Server [now Sybase ASE] were decades ahead of it). I had the starry-eyed view that Date; Darwen; Fagin; etc, were well-intentioned in their promotion of error as “relational”, and merely ignorant academics who were divorced from the industry due to the declaration that theory should not concern itself with implementation. So I took to TTM to engage and inform them, to clear the ignorance. That is, I too, believed in the marketing that they were the “curators” of the /Relational Model/, after all the SQL Committee were treating them as such, and making stupid changes.

In hindsight, that was my first crusade, I had made an awful lot of money and I wanted to give something back to my profession; I was responsible enough as a scientist, to correct errors; and I went to the source of those errors and addressed them directly.

It took three years of hard labour at the TTM gulag, for me to realise:
- they are stupid academics, caught up in their academic denial of reality, so that they can manufacture a collective subjective “reality”
- they practice, and teach, schizophrenia, not science, which they have no interest in
--- worse, they suppress science, and market schizophrenia. Eg. they argue for years about any particular subject, resolving nothing (no Four Laws of Thought)
- they never had any impact on the implementation platforms, and due to their evidenced capability, they never will
--- (the exception is of course Codd, but he was not one of them, he was typical of the scientists who worked for the DBMS implementation platforms, and progressed them. He had specific implementation goals. The /RM/ is a progression of HDBMS and NDBMS, not at all an entirely new and different thing. Yes, of course it is the first to have a defined theoretical basis; a mathematical definition; it is based on FOPC.)
- they hate Codd. They take every opportunity to deride him and demean his work. the /RM/, 80% of which is completely false and dishonest (eg. Straw Man arguments), and 20% stupidity (eg. expecting the /RM/ to teach database design and how to tie their shoelaces). Even an undergrad knows that a paper defines the proposal, not everything prior that the proposal depends upon.
- and thus that they were intentionally suppressing the Logical /RM/; intentionally articulating Physical 1960’s Record Filing Systems as “relational”, as a “progression of the /RM/“, and fraudulently using RM/T and the 1971 paper as a basis for that.
- at the top of the food chain, it was not the entrenched stupidity and ignorance of academics, which all of them suffer from and protect, but purposeful evil: they are propagating anti-science
- all the textbooks are written by such freaks, all the so-called professors teach such filth without examination, deeming themselves too, as schizophrenic anti-scientists
- to remain divorced from the theory for FIFTY YEARS; to remain ignorant of actual Standards and implementation platforms for FORTY YEARS, does not happen accidentally, or as a consequence of stupidity and ignorance, no, that happens only by design

During that three years, I innocently and diligently addressed each of the several idiocies that TTM is: “deferred constraint checking”; “headings”; “relvars”; etc. Then there was the business where they were going to “define” “transactions”. Oh wait, for FORTY YEARS at that point they divorced themselves from implementation concerns and had nothing to say about implemented SQL platforms that supplied ACID Transactions, but now (then) that they were defining a Torrid Manifestival (manifestation of fantasy) to replace SQL, they were going to define “transactions”. From scratch. Reinventing the wheel. On the pretended basis that it did not yet exist. An imaginary piece of string that connects unidentified verbs together.

So I tried desperately, to tell them about considerations in an OLTP context (rather than the isolated tiled room they insisted is “reality”). As always with academics, at first, they expressed interest and engaged, but less than half-way through they just stopped engaging. SO nothing was resolved, which is their end game, they need that non-resolution, so that they can circle-jerk and argue amongst themselves without producing a single thing as they have done for FIFTY YEARS (then FORTY YEARS).

They wanted to drop ACID, per per one of the chief sow-suckers papers, and they were fantasising just like they had dropped some, and it was a bad trip. But they were partying in the sow stall in company, so they had a lot of confidence in their collective fantasy. The only Dates he has had is with a 300 pound sow. Nothing real; nothing concrete or “concrete”; the “definitions” kept changing every time I brought up a point from Reality.

As you can see from the Transaction Grid, I was entertaining their fantasy (Green, “RM TTM/D”) and comparing it against the ACID Transactions in implementations since 1965. The “RM” in the heading is of course false: it was a concession at the time, as I had not yet determined their evil intent.

On that document, there was another six pages to go, to achieve closure (either a fixed definition of TTM/“transactions”, xor them conceding that ACID Transactions were established since 1965, and again in the 1980’s on SQL platforms, and it was unshakable.
<<<<

Please ignore that doc. It had a specific purpose, a drawn-out discourse and argumentation re TTM/“transactions”.

Please be assured, I am giving you a complete discourse in this thread, as requested, without the interference of the TTM or academic insanity. This thread and the doc I have given here, is far more detailed, and will be complete at the end.

But the cat is out of the bag. The problem now is, you have knowledge of the label of the problem (third of four categories), and even the label for the solution (for all four), but you do not yet understand the problem properly, which is an essential requirement for coding for OLTP without errors (just coding per a Template does not work, understanding it is essential). I am giving the course I give to customers, minus the slides and a bit of proprietary stuff. The course has not changed since I first created it in 1993, it is stable, it has a sequence, and the sequence has a purpose: incremental learning and thus full comprehension.

> Now I'm not entirely sure if it's in the same class of problem as anomalies / deadlocks / lost updates, but since you've spoken about sociable behaviour already I'm going to go out on a limb and say 'contention management'.
>
> With proper contention management leading to higher performance, and poor contention management (e.g.: gratuitously acquiring locks needlessly) leading to low performance.

Yes, correct.

Not only acquiring and holding more locks than necessary, but reducing (a) the locks held, (b) the lock duration, (c) holding locks at the highest level, thus holding fewer locks, and (d) preventing deadlocks with an Access Sequence.

----

I see that the four categories of OLTP considerations/problems well-known since 1965, and solved 1965 for mainframes; 1984 for SQL platforms, is not entirely clear. I will clarify that in the next version of the Transaction Sanity doc. To identify that here, and mark the progress of this thread:


Click here to read the complete article
Re: Checkpoint & Consolidated Doc

<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=192&group=comp.databases.theory#192

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:620a:a5a:: with SMTP id j26mr13245654qka.42.1627218505223;
Sun, 25 Jul 2021 06:08:25 -0700 (PDT)
X-Received: by 2002:a9d:12e1:: with SMTP id g88mr8426647otg.36.1627218504980;
Sun, 25 Jul 2021 06:08:24 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Sun, 25 Jul 2021 06:08:24 -0700 (PDT)
In-Reply-To: <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.78; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.78
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Sun, 25 Jul 2021 13:08:25 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Sun, 25 Jul 2021 13:08 UTC

> On Sunday, 25 July 2021 at 22:33:22 UTC+10, Derek Ignatius Asirvadem wrote:
> > On Saturday, 24 July 2021 at 20:47:50 UTC+10, Daniel Loth wrote:
> >
> > I read the PDF you put together years ago: http://www.softwaregems.com.au/Documents/The%20Third%20Manifesto/Transaction%20TTM%20101122.pdf
>
> Crikey. A bit of context is demanded.
>
> >>>>
> In hindsight, that was my first crusade, I had made an awful lot of money and I wanted to give something back to my profession; I was responsible enough as a scientist, to correct errors; and I went to the source of those errors and addressed them directly.
....
> <<<<

Put another way, I gave the freaks full definition of Lost Update, and the full definition of the solution Optimistic Locking, eleven years ago ... but the drooling idiots still have not got it. Codd and I suffer the same thing from them: the Not Invented Here Syndrome. We are not pure academics, masturbating over our fantasies that have no connection to reality. They ignore and suppress Reality; the genuine SQL platform implementations; Transactions; ACID; anything they did not invent themselves, even if it is fifty years after it has been implemented in Reality.

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=193&group=comp.databases.theory#193

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:620a:ceb:: with SMTP id c11mr16296749qkj.331.1627301432585;
Mon, 26 Jul 2021 05:10:32 -0700 (PDT)
X-Received: by 2002:a4a:2a05:: with SMTP id k5mr10227118oof.0.1627301432317;
Mon, 26 Jul 2021 05:10:32 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Mon, 26 Jul 2021 05:10:32 -0700 (PDT)
In-Reply-To: <f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=193.119.51.108; posting-account=S056qgoAAAASvuIiqcdQPeaQ70w-ZkVa
NNTP-Posting-Host: 193.119.51.108
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: daniel.j...@gmail.com (Daniel Loth)
Injection-Date: Mon, 26 Jul 2021 12:10:32 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Daniel Loth - Mon, 26 Jul 2021 12:10 UTC

Hi Derek,

> So did the example Transaction persist, or was it wiped out by a similar Transaction ?
> - by your definition of [D]urable, the Transaction is fine, the Lost Update is unknown (happens all the time, and people are ignorant that it happens).
> - by the IBM definition, the Transaction failed, it did not persist, it is not [D]urable. The Lost Update is known.

So you're talking about notions of physical durability (i.e., my data is written to non-volatile storage and will endure) -- versus -- logic durability (i.e., my data is written and other users of this system who might be operating on the same data will not clobber it without being informed that my transaction has occurred in the period of time between them viewing the data and attempting to act upon it).

> But how is it prevented ?

In Microsoft SQL Server the most robust way is using the ROWVERSION data type, which is just a very large monotonic integer that is automatically updated when modifying a record in a table with a column of type ROWVERSION. It's essentially timestamp based concurrency control.

Of course, you needn't use ROWVERSION specifically. You could conceivably use some other very large value (a GUID / UUID for example) so long as you a) update it on all occasions where you're modifying the data it protects and b) always check it before proceeding with a data modification.

---

Thanks for the background re: the TTM discussion. I came across it while looking at other stuff, and it was actually quite eye-opening at the time. In fact that's how I came across the notion of timestamp based concurrency control.

---

> Question. What is the *BASIS* for the user having confidence that their Transaction will (should) work ?

In a well-designed system? The knowledge that the system won't allow them, or anyone else, to unknowingly overwrite someone else's changes.

In an abstract sense? Maybe they've had some degree of exposure to notions such as 'Durability' and, in laymen's terms, perceived it as something that will safeguard their modifications from data loss.

---

> How do the naïve developers who use an OLTP/SQL platform (especially if they have only MV-non-CC+application locking mindset) prevent Lost Updates ?

The naive approach would be to acquire and hold locks for the duration of user activity right? That is, acquire and hold some kind of lock at the time a user opens a screen to view some data, and then release that lock when the user finishes with the screen.

Though in my personal experience, I haven't seen this.

I have instead seen:
1. No attempted lost update prevention at all. Last update wins.
2. Timestamp based concurrency control, but weakly implemented. For example, the notion exists but might not be used appropriately in all places in application code. Or alternatively, the breadth of data protected by a particular timestamp is too coarse or too fine. Or alternatively again, there is confusion about which timestamps protect which data from lost updates.

---

Cheers,
Dan

Re: Checkpoint & Consolidated Doc

<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=194&group=comp.databases.theory#194

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ac8:47c5:: with SMTP id d5mr17096396qtr.231.1627343978994;
Mon, 26 Jul 2021 16:59:38 -0700 (PDT)
X-Received: by 2002:a4a:b189:: with SMTP id c9mr11924636ooo.30.1627343978737;
Mon, 26 Jul 2021 16:59:38 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Mon, 26 Jul 2021 16:59:38 -0700 (PDT)
In-Reply-To: <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.138; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.138
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Mon, 26 Jul 2021 23:59:38 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 12280
 by: Derek Ignatius Asirv - Mon, 26 Jul 2021 23:59 UTC

> On Monday, 26 July 2021 at 22:10:33 UTC+10, Daniel Loth wrote:
>
> > So did the example Transaction persist, or was it wiped out by a similar Transaction ?
> > - by your definition of [D]urable, the Transaction is fine, the Lost Update is unknown (happens all the time, and people are ignorant that it happens).
> > - by the IBM definition, the Transaction failed, it did not persist, it is not [D]urable. The Lost Update is known.
>
> So you're talking about notions of physical durability (i.e., my data is written to non-volatile storage and will endure) -- versus -- logic durability (i.e., my data is written and other users of this system who might be operating on the same data will not clobber it without being informed that my transaction has occurred in the period of time between them viewing the data and attempting to act upon it).

(I am not adding to, or subtracting from, the IBM definition.)

The distinction you make between logical vs physical muddies the water, so remove it. Think: online database containing a single version of the truth, of any one fact. Yes, that is logical, and we don’t have to worry about the physical (which is site- or server-specific).

You are focused on the notion that persistence is provided by the physical. It is not. If you hold any OO/ORM/OOP connotations re /persist/, release them. Here /persist/ means only the English meaning plus the technical scope.

Second, don’t think in terms of /data/, which is fragments, and tends toward the physical. Think in terms of Atoms, Transactions, which is the Logical. Users do not know about, and couldn’t care less about, the physical.

So, taking only the Logical in your response:
> logic durability (i.e., my data is written and other users of this system who might be operating on the same data will not clobber it without being informed that my transaction has occurred in the period of time between them viewing the data and attempting to act upon it).

Yes, that is the result, working backwards.

We need to understand it forwards. His Transaction completed and it persists ... and therefore he has confidence in the system. XOR his Transaction completed, but it did not persist ... and therefore he has no confidence in the system. Transaction Sanity/p4. Was the Transaction Durable or not ?

> > But how is it prevented ?
> In Microsoft SQL Server the most robust way is using the ROWVERSION data type, which is just a very large monotonic integer that is automatically updated when modifying a record in a table with a column of type ROWVERSION. It's essentially timestamp based concurrency control.

Correct.
But that is not robust, it is a large overhead. A data-level TimeStamp (DATETIME datatype) is the most robust. We have had that since 1965, 1984 for RDBMS, forty years before MS implemented ROWVERSION.

Much like the massively resource-eating HIERARCHYID. We have had hierarchies and full exposition of hierarchies in databases since 1965, 1984 in RDBMS, which is zero overhead. No CTEs; no WITH. Forty years before MS gave us HIERARCHYID; WITH; CTEs.

> Of course, you needn't use ROWVERSION specifically. You could conceivably use some other very large value (a GUID / UUID for example) so long as you a) update it on all occasions where you're modifying the data it protects and b) always check it before proceeding with a data modification.

For the concept, yes.
For the implementation, definitely not, because (a) GUID; UUID; etc has the purpose of establishing uniqueness, which we do not need, (b) it is very high overhead. Just a DATETIME (millisecond resolution is just fine, no need for microseconds, which is useful for actual row version). The column may be named TimeStamp; UpdatedDtm; something meaningful ... certainly not RowVersion.

Considering portability, ROWVERSION is not SQL, TimeStamp[ DATETIME ] is. Nothing to change when porting.

> Thanks for the background re: the TTM discussion. I came across it while looking at other stuff, and it was actually quite eye-opening at the time. In fact that's how I came across the notion of timestamp based concurrency control.

Good to know that someone benefits from my efforts.

> > Question. What is the *BASIS* for the user having confidence that their Transaction will (should) work ?
> In a well-designed system? The knowledge that the system won't allow them, or anyone else, to unknowingly overwrite someone else's changes.
>
> In an abstract sense? Maybe they've had some degree of exposure to notions such as 'Durability' and, in laymen's terms, perceived it as something that will safeguard their modifications from data loss.

It is not a /maybe/. The app & database provider tells them that: “we provide ACID Transactions” (it is articulated in the standard SG contract, which refers to our Trade Practices Act 1974; “fitness for purpose”; etc).

Second, in their user training, the issue will come up; be discussed; be resolved. SO it is not just abstract, it is logical and explicit.

The mickey mouse app & db providers; all who follow the academics or MV-non-CC, are clueless, they rely on the ignorance of the definition of [D]urable, that it pertains only to the physical (the system is durable). They do not know that Transactions have to be [D]urable.

You have gotten very close, but not directly answered this:
> > Question. What is the *BASIS* for the user having confidence that their Transaction will (should) work ?
I am provoking a thought process in your mind. Focus on *BASIS*. Here you have to get rid of any MV-non-CC or “MVCC” notions because they are bankrupt. Think in terms of Reality, an online shared database that contains a single version of any single fact.

I am trying to get you to experience an illumination, which is difficult in this medium. At best, you will further recognise that an MV-non-CC or “MVCC” mindset is schizophrenic, that it denies reality, and that the *BASIS* for confidence in a true OLTP system, which is ordinary, is denied.

Thus the *BASIS* for confidence is the principle. The basis for confidence of any retrieved data, in any retrieval, is not the data itself, or it accuracy or its veracity, but the TimeStamp.

This is true even for paper-based systems. Eg. the Lost Update cannot happen in a paper-based system.

>
> ---
> > How do the naïve developers who use an OLTP/SQL platform (especially if they have only MV-non-CC+application locking mindset) prevent Lost Updates ?
> The naive approach would be to acquire and hold locks for the duration of user activity right?

Yes.

That is, acquire and hold some kind of lock at the time a user opens a screen to view some data,

Yes.

and then release that lock when the user finishes with the screen.

By “finish”, if you mean the Transaction completes, yes.

That means:
- BEGIN TRAN is done in the client
- locks are held for an uncontrolled duration (coffee; phone calls; toilet breaks; etc)
- the system will be lock-bound
- guaranteed contention
Therefore the app & db totally fails OLTP

Further, it fails [A]tomic, because the string of SQL between BEGIN and COMMIT is not controlled; not a single contiguous code block. It is spread across various client-side objects, in terms of execution, it is spread across the network.

>
> Though in my personal experience, I haven't seen this.

That depends on whether you have worked on any systems that declare “OLTP” or not. Eg. in the “MVCC” mindset, which is actually MV-non-CC, it happens all the time, because they have to *additionally* implement Concurrency Control via manual locking.

More than 80% of the systems we have replaced, the Version One, and half of that was commercial products, have this problem. Generally terrible Transaction implementation, and some degree of naïve locking to overcome [found instances of] failures.

In MySQL, the manual locking is correct, one provides an user-level lock name, such that it is entirely in the app/database, and entirely without the server. Safe.

In PissGress, manual locking engages the Lock Manager which sits on top of the MV-non-CC, guaranteeing interference bewteen server-level locking and app+dd level locking. Dangerous and stupid.

> I have instead seen:
> 1. No attempted lost update prevention at all. Last update wins.
> 2. Timestamp based concurrency control, but weakly implemented. For example, the notion exists but might not be used appropriately in all places in application code. Or alternatively, the breadth of data protected by a particular timestamp is too coarse or too fine. Or alternatively again, there is confusion about which timestamps protect which data from lost updates.

Ok. So you have some experience of the methods; and the poor or partial implementations. Typically that happens when someone finds a good template but does not fully understand the problem, or the solution. Which is why I stress that in our discussion.

We have completed [B.1], if you are clear about the *BASIS* above, ...

----

you are ready for [B.2], the fourth and last category of known and preventable errors in an OLTP context. Transaction Sanity/page 5. Note the changes on p2.

__ https://www.softwaregems.com.au/Documents/Article/Database/Transaction/Transaction%20Sanity.pdf

Please discuss.

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<47ee4839-9974-4841-8b49-6b86e32eab0en@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=195&group=comp.databases.theory#195

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a0c:f14f:: with SMTP id y15mr19239907qvl.12.1627383563657;
Tue, 27 Jul 2021 03:59:23 -0700 (PDT)
X-Received: by 2002:aca:3144:: with SMTP id x65mr14337470oix.157.1627383563424;
Tue, 27 Jul 2021 03:59:23 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Tue, 27 Jul 2021 03:59:23 -0700 (PDT)
In-Reply-To: <69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=193.119.51.108; posting-account=S056qgoAAAASvuIiqcdQPeaQ70w-ZkVa
NNTP-Posting-Host: 193.119.51.108
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <47ee4839-9974-4841-8b49-6b86e32eab0en@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: daniel.j...@gmail.com (Daniel Loth)
Injection-Date: Tue, 27 Jul 2021 10:59:23 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Daniel Loth - Tue, 27 Jul 2021 10:59 UTC

Hi Derek,

Thanks for the response and continued discussion.

---

>We need to understand it forwards. His Transaction completed and it persists ... and therefore he has confidence in the system. XOR his Transaction completed, but it did not persist ... and therefore he has no confidence in the system. Transaction Sanity/p4.

> Was the Transaction Durable or not ?

No. Neither the User 1 or User 2 transactions make use of the timestamp based concurrency control.

---

> Correct.
> But that is not robust, it is a large overhead. A data-level TimeStamp (DATETIME datatype) is the most robust. We have had that since 1965, 1984 for RDBMS, forty years before MS implemented ROWVERSION.

If you're using a clock-based timestamp such as DATETIME, instead of a server-wide monotonic integer (which is what the Microsoft ROWVERSION is), what do you do to handle the possibility of clock skew on the database server?

Do you do anything, or do you just take your chances? I recognise that the situation is extraordinarily rare, and you may typically dismiss it on that basis.

On the other hand, I noticed that the procedure 'Dumb_Withdraw_tr' actually takes @UpdatedDtm as a parameter, which conceivably is another source of clock skew when the caller specifies the time (or even lies about the time).

---

> I am provoking a thought process in your mind. Focus on *BASIS*. Here you have to get rid of any MV-non-CC or “MVCC” notions because they are bankrupt. Think in terms of Reality, an online shared database that contains a single version of any single fact.

So what you're getting at, especially with the mention of paper-based, is: It's inconceivable that you could inadvertently clobber someone else's change to that single piece of paper without being cognisant of that. After all, they've written on the paper and put it back, and then you've picked it up and looked at it. Obviously being a single piece of paper, without duplicates, access to the piece of paper involves queuing up for it and waiting your turn.

---

I'll take a look at that updated PDF now, though I might not respond again until tomorrow.

Cheers,
Dan

Re: Checkpoint & Consolidated Doc

<sdor6j$1vsl$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=196&group=comp.databases.theory#196

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!bLslxARt4KJIr8VsYMTiug.user.46.165.242.75.POSTED!not-for-mail
From: nic...@nohost.com (Nicola)
Newsgroups: comp.databases.theory
Subject: Re: Checkpoint & Consolidated Doc
Date: Tue, 27 Jul 2021 11:37:55 -0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <sdor6j$1vsl$1@gioia.aioe.org>
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org>
<6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org>
<0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com>
<24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com>
<7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com>
<3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com>
<17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com>
<8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com>
<29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="65429"; posting-host="bLslxARt4KJIr8VsYMTiug.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Nicola - Tue, 27 Jul 2021 11:37 UTC

Hi all,
I am back, too, and trying to catch up with the discussion, but not
there yet.

Derek, I have read your Transaction Sanity document. When academics
discuss "transactions", they do so in the context of what eventually
becomes a start transaction… commit block in implementations. For
instance, they ask themselves: under what conditions are lost updates
(and other anomalies) be avoided when:

-- Transaction 1
start transaction;
-- Perform some operations, including updates
commit;

-- Transaction 2
start transaction;
-- Perform some operations, including updates
commit;

are executed concurrently? Admittedly, the examples that are usually
found in textbooks are quite misleading: the classical fund transfer is
used because the context is readily understood, but it should be taken
with a grain of salt, and certainly not as a way to suggest how a real
banking transaction should be implemented. It's naive to think that the
"naive solution" in your document is what a (good) teacher would suggest
as a practical way to solve the problem stated in that document. To make
the point clearer (and simplifying things a bit): the transaction theory
that we teach, and which you can find in (good) textbooks, is the theory
you would need to write a transaction manager for a DBMS (i.e., the
theory needed by Sybase developers), rather than the theory needed to
correctly implement the transactions for a banking system or any other
application, which builds on top of the former and is seldom, if ever,
discussed in textbooks. Hence, I am eager to hear what you have to say
about it. Even got SQL Server and Sybase installed to verify your claims
:)

Nicola

Correction

<d1daf4a4-06ce-439f-af90-23dc7d01c772n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=197&group=comp.databases.theory#197

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a0c:f6c6:: with SMTP id d6mr24887192qvo.30.1627420168003;
Tue, 27 Jul 2021 14:09:28 -0700 (PDT)
X-Received: by 2002:a9d:6c1:: with SMTP id 59mr16242767otx.318.1627420167737;
Tue, 27 Jul 2021 14:09:27 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Tue, 27 Jul 2021 14:09:27 -0700 (PDT)
In-Reply-To: <47ee4839-9974-4841-8b49-6b86e32eab0en@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.138; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.138
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com> <47ee4839-9974-4841-8b49-6b86e32eab0en@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d1daf4a4-06ce-439f-af90-23dc7d01c772n@googlegroups.com>
Subject: Correction
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Tue, 27 Jul 2021 21:09:27 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Derek Ignatius Asirv - Tue, 27 Jul 2021 21:09 UTC

> On Tuesday, 27 July 2021 at 20:59:24 UTC+10, Daniel wrote:

> I noticed that the procedure 'Dumb_Withdraw_tr' actually takes @UpdatedDtm as a parameter

Ouch. Copy-paste error. Please ignore. Doc updated. Please discuss against the corrected doc.

What skew ???

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<99467d73-1fce-47d9-960b-1ff0a1e0bc85n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=198&group=comp.databases.theory#198

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ac8:6708:: with SMTP id e8mr20785386qtp.166.1627423429914; Tue, 27 Jul 2021 15:03:49 -0700 (PDT)
X-Received: by 2002:a54:4895:: with SMTP id r21mr16023071oic.30.1627423429710; Tue, 27 Jul 2021 15:03:49 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Tue, 27 Jul 2021 15:03:49 -0700 (PDT)
In-Reply-To: <d1daf4a4-06ce-439f-af90-23dc7d01c772n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.138; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.138
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com> <b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com> <6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com> <sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com> <sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com> <sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com> <06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com> <163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com> <ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com> <7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com> <86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com> <f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-14
92-4bd4-992f-a6900e83f8a2n@googlegroups.com> <69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com> <47ee4839-9974-4841-8b49-6b86e32eab0en@googlegroups.com> <d1daf4a4-06ce-439f-af90-23dc7d01c772n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <99467d73-1fce-47d9-960b-1ff0a1e0bc85n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Tue, 27 Jul 2021 22:03:49 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 90
 by: Derek Ignatius Asirv - Tue, 27 Jul 2021 22:03 UTC

> On Tuesday, 27 July 2021 at 20:59:24 UTC+10, Daniel wrote:
> Hi Derek,
>
> Thanks for the response and continued discussion.

It is my pleasure.
>
> ---
> >We need to understand it forwards. His Transaction completed and it persists ... and therefore he has confidence in the system. XOR his Transaction completed, but it did not persist ... and therefore he has no confidence in the system. Transaction Sanity/p4.
>
> > Was the Transaction Durable or not ?
> No. Neither the User 1 or User 2 transactions make use of the timestamp based concurrency control.

Yes, that is the back end, or developer’s understanding.

What is in the user’s mind, how does he perceive it ?

> ---
> > Correct.
> > But that is not robust, it is a large overhead. A data-level TimeStamp (DATETIME datatype) is the most robust. We have had that since 1965, 1984 for RDBMS, forty years before MS implemented ROWVERSION.
> If you're using a clock-based timestamp such as DATETIME, instead of a server-wide monotonic integer (which is what the Microsoft ROWVERSION is), what do you do to handle the possibility of clock skew on the database server?

What skew ??? Where is this skew ???

> Do you do anything, or do you just take your chances? I recognise that the situation is extraordinarily rare, and you may typically dismiss it on that basis.

I can’t answer the “skew” part directly because I don’t know what you mean. Re allowing a skew (if there was one), definitely not, I would not do that (we cater for extreme high transaction rates; race conditions; etc in high end Stock Trading environments). The Template has not changed since 1993, it required minor tweaks to cater for the new (additional) Data Storage structure for RFS type files when Sybase ASE 12 came out (IIRC 1999).

Second question, why choose a monotonic number that the server has to generate and maintain ?

(
The original Sybase 4.2 Datatype was TIMESTAMP. It is not a monotonic number but similar. It is a metric, in essence it is the number of writes to the database. A database-wide currency number. It can be compared [the purpose] but it cannot be examined. ROWVERSION is the bastard son’s copy of his father’s method. ROWVERSION is a horrible name for it, it is just another magic number, that the server has to maintain, same as a GUID or UUID as used for RecordId.

TIMESTAMP is not deprecated, but it is ancient, no one I know uses it. Not becauee it does not work, but because it cannot be examined. A column eg. /TimeStamp/ or /UpdatedDtm/ (Datatype DATETIME, millisec resolution, no need for microsec resolution) is commonly used.
)

> ---
> > I am provoking a thought process in your mind. Focus on *BASIS*. Here you have to get rid of any MV-non-CC or “MVCC” notions because they are bankrupt. Think in terms of Reality, an online shared database that contains a single version of any single fact.

> So what you're getting at, especially with the mention of paper-based, is: It's inconceivable that you could inadvertently clobber someone else's change to that single piece of paper without being cognisant of that. After all, they've written on the paper and put it back, and then you've picked it up and looked at it. Obviously being a single piece of paper, without duplicates, access to the piece of paper involves queuing up for it and waiting your turn.

Yes. Excellent parallels drawn. Keep going.
- In the paper system, the person (first-up in the queue) would have be cognisant.
- think: a library card system, arranged in 200 little drawers for convenience of physical access by many people
- In the automated system, the program has to be cognisant.
- In the paper system, the person (first-up in the queue for a particular card) has an idea of its data currency based on something, so that when he returns (with the intended update), he would be cognisant that the card has changed.
- In the automated system, the program has to do that.

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<e0eea525-63ff-4618-8629-c583666d32e7n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=199&group=comp.databases.theory#199

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:620a:1193:: with SMTP id b19mr24274388qkk.439.1627433398016;
Tue, 27 Jul 2021 17:49:58 -0700 (PDT)
X-Received: by 2002:aca:34c4:: with SMTP id b187mr6649749oia.139.1627433397733;
Tue, 27 Jul 2021 17:49:57 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Tue, 27 Jul 2021 17:49:57 -0700 (PDT)
In-Reply-To: <sdor6j$1vsl$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.138; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.138
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com> <sdor6j$1vsl$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e0eea525-63ff-4618-8629-c583666d32e7n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Wed, 28 Jul 2021 00:49:58 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Wed, 28 Jul 2021 00:49 UTC

> On Tuesday, 27 July 2021 at 21:37:57 UTC+10, Nicola wrote:

> I am back, too,

Good to have you back.

> Derek, I have read your Transaction Sanity document. When academics
> discuss "transactions", they do so in the context of what eventually
> becomes a start transaction… commit block in implementations. For
> instance, they ask themselves: under what conditions are lost updates
> (and other anomalies)

I don’t accept that. They don’t even know about Lost Updates. There is nothing in the literature about it.

Further, /By their fruits ye shall know them/. For more than twenty years, the CS grads we hire have no clue about these issues, meaning that they are taught nothing about real world Transactions. BIg corporations pay big money to get their developers educated precisely because they are not educated in the “education” system, they are ignorant of CS even though their degree is CS.

> be avoided when:
>
> -- Transaction 1
> start transaction;
> -- Perform some operations, including updates
> commit;
>
> -- Transaction 2
> start transaction;
> -- Perform some operations, including updates
> commit;
>
> are executed concurrently?

There is not enough detail in that to say anything, one way or the other. It is just two generic code segments. Give it more detail and ask a specific question.

Starting from scratch is insanity.

> Admittedly, the examples that are usually
> found in textbooks are quite misleading: the classical fund transfer is
> used because the context is readily understood, but it should be taken
> with a grain of salt, and certainly not as a way to suggest how a real
> banking transaction should be implemented.

I don’t have a problem with that particular example. I have a problem that the textbooks give no further examples, that they do not get into the issues (contention; reduction; concurrency; etc). The textbooks have a consistent single-user mindset, promoting schizophrenia.

> It's naive to think that the
> "naive solution" in your document is what a (good) teacher would suggest
> as a practical way to solve the problem stated in that document.

I did not say that a teacher taught them that, no idea where you got that. I can’t defend what I did not say.

I said (you can take implications of what I said), that naïve developers do that. Precisely because they are clueless re the consequences, precisely because they are NOT taught anything about OLTP (technology in the real world since 1965, on SQL Platforms since 1984). The sequence is:
- they code “transactions” badly, with no template
- they deliver the system with minimal testing
- everything looks fine
- as more and more users start using the system, Transactions disappear; money is given to people who are barred from receiving that money; deadlocks start to happen; etc
- a vague notion that the system had concurrency problems is formed
- the developers scramble to fix the worst few “transactions” and the most obvious; the easiest, thing to do is BEGIN TRAN in the client
- it immediately fixes the lost data; lost “transaction” problems, so they have confidence in that particular band-aid
- but it introduces massive lock contention

> To make
> the point clearer (and simplifying things a bit): the transaction theory
> that we teach, and which you can find in (good) textbooks, is the theory
> you would need to write a transaction manager for a DBMS (i.e., the
> theory needed by Sybase developers),

1. For Sybase Engineers (your “developers”)
You have said some silly things in the ten years that you and I have conversed, but that is definitely the silliest. As per the evidence (not a claim; not an opinion), the academics (
a) maintain a steadfast denial of the real world; of the industry; of the facilities in commercial SQL Platforms,
(b) theorise about a contrived notion of the real world; a contrived notion of the industry; a contrived notion of the facilities in commercial SQL Platforms, aka FANTASY
(c) as evidenced in hundreds of papers that produce sweet fanny adams, that have zero effect on the real world; on the industry; on commercial SQL Platforms
(d) and they are going to tell Engineers of commercial SQL Platforms, who wrote the THEORY, and who still today write progressions to the theory (most are PhDs)
(e) about the commercial SQL Platforms that were established FORTY YEARS ago, and have FORTY YEARS of maturity, that are secured with scores of PATENTS (as well as proprietary methods)
(f) FORTY YEARS after the fact.

I love it. You can’t make this stuff up. If it was not in writing, no one would believe it.

The is the same cultivated insanity that academics who allege to be in this field have, and have had since 1970. Inventing the wheel from scratch requires the denial that the wheel was invented FIFTY YEARS ago. Theorising about “semantic models” FORTY YEARS after IDEF1X, in hysterical ignorance that the /RM? is based on FOPC; Predicates; that any suggested model has to be Logic; Mathematics; Semantic.

This is the same hilarious inferiority complex (presenting as “superiority complex”) that academics have. This is the same idiocy that Date; Darwen; Fagin; etc have, trying to say that they can teach anything, ANY THING, about the /RM/, or progress the /RM/.

Remember, Codd was not an academic, he was a scientist who worked for a platform supplier. The academics never accepted him, they have not produced a single progression of the /RM/, but they have produced hundreds of papers promoting 1960’s Record Filing Systems fraudulently labelled as “relational”.

2. Example
Ok, take it another way, provide one single example of a thing that academics have produced that “Sybase Engineers” need.

3. For wannabe ArrDeeBeeEmEss developers
Even that is stupid. Why on earth would anyone theorise about something that has been implemented and proved for FIFTY YEARS ?

>>>>
Here is my take on science, as it has been 350BC to 1911. (Which is under attack since 1911, by Modernism.) It is a body of knowledge (certainty: the Latin word means knowledge not speculation). Of course, one can speculate BASED ON that body of knowledge, and that is HYPOTHESIS, which when confirmed by tests is elevated to THEORY. If and when the theory is proved (proper proof, proper method, not merely a mathematical definition of a theory), it progresses to a truth, and is added to that body of knowledge.

When that theory, which is proved in one or the other vertical gets proved in many verticals, it is elevated to LAW, such as the LAW of Thermodynamics, and it applies to all other sciences. Eg. evolutionism fails the second LAW of Thermodynamics.
<<<

OLTP is LAW. The proof in the mainframe rendition was fixed in 1965. The proof for the minicomputer rendition and SQL Platforms was fixed in 1984 (Britton-Lee in the late 1970’s). I was benchmarking CINCOM/TOTAL NDBMS against Britton-Lee proprietary DBMS in 1979. (Britton-Lee became Sybase in the SQL rendition.) Nothing has changed.

Anyone theorising about OLTP after 1984 is in schizophrenic denial of the real world. The hallmark; the proudly declared badge, of academics in this field. They openly declare that implementation concerns are divorced from theory. Thus their theory is fantasy, about a problem that has been solved FIFTY YEARS ago.

Oh wait, now that they are pushing PissGress, which is an “implementation”, suddenly they have started theorising about implementations, contradicting their own declaration. But it is still divorced from reality, a contrived fantasy. Instead of finding out what Commercial SQL Platforms have doen for FORTY YEARS, they deny its existence, and contrive to invent the wheel, from scratch.

What is demanded, what is NOT taught, is education about the real world, education about OLTP LAW. Instead, you guys teach a MV-non-CC or “MVCC” mindset, and no OLTP at all.

Separate point. If you want to theorise about something that relates to Transaction Processing, that might illuminate the subject, study chip technology, particularly the advances in [software, live objects] THREADS. It is not a coincidence that Sybase ASE uses a single unix process for the server, and multiple software THREADS internally (fully configurable) ... that, wait for it ... handle multiple user THREADS, some of which are competing Transactions.

It is with the same level of stupid, and the same level of schizophrenia, that academics teach ERD for “relational” modelling, or theorise about “semantic models”, FIFTY YEARS after IDEF1X, FORTY YEARS after it was established as a Standard.

Put another way, just look at the stupefying “implementation” known as PoopDePoopGress, that evidences the level of theorising that the academics actually theorise about, that they are aware of.

--------------------------------
WAKE THE FROG UP
---------------------------------------------------------------
IT IS A BACKWARD PIECE OF PIG POOP
------------------------------------------------------------------------------------------------------------------------------------------------------------
IT DOES NOT HAVE EVEN THE BASICS THAT COMMERCIAL RDBMS HAVE HAD, FOR FIFTY YEARS
------------------------------------------------------------------------------------------------------------------------------------------------------------

You can’t make this stuff up. About two hundred programs competing like the asylum dwellers that wrote it, pretending to be a server, hosting multiple stale offline versions or records, with a determination to deny reality of Online; of Transactions; of Processing. That is the evidenced level of your theorising. People who have not lost their brains identify that as contrived fantasy.


Click here to read the complete article
Science vs Pseudo-Science; Modern "Science"

<a49e332f-b960-420b-9103-84c353649205n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=200&group=comp.databases.theory#200

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:6214:2485:: with SMTP id gi5mr70918qvb.36.1627439672455;
Tue, 27 Jul 2021 19:34:32 -0700 (PDT)
X-Received: by 2002:a9d:2f47:: with SMTP id h65mr17687495otb.299.1627439672235;
Tue, 27 Jul 2021 19:34:32 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Tue, 27 Jul 2021 19:34:32 -0700 (PDT)
In-Reply-To: <e0eea525-63ff-4618-8629-c583666d32e7n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.138; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.138
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com> <sdor6j$1vsl$1@gioia.aioe.org>
<e0eea525-63ff-4618-8629-c583666d32e7n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a49e332f-b960-420b-9103-84c353649205n@googlegroups.com>
Subject: Science vs Pseudo-Science; Modern "Science"
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Wed, 28 Jul 2021 02:34:32 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Wed, 28 Jul 2021 02:34 UTC

> On Wednesday, 28 July 2021 at 10:49:58 UTC+10, Derek Ignatius Asirvadem wrote:
> > On Tuesday, 27 July 2021 at 21:37:57 UTC+10, Nicola wrote:
>
> >>>>
> Here is my take on science, as it has been 350BC to 1911. (Which is under attack since 1911, by Modernism.) It is a body of knowledge (certainty: the Latin word means knowledge not speculation). Of course, one can speculate BASED ON that body of knowledge, and that is HYPOTHESIS, which when confirmed by tests is elevated to THEORY. If and when the theory is proved (proper proof, proper method, not merely a mathematical definition of a theory), it progresses to a truth, and is added to that body of knowledge.
>
> When that theory, which is proved in one or the other vertical gets proved in many verticals, it is elevated to LAW, such as the LAW of Thermodynamics, and it applies to all other sciences. Eg. evolutionism fails the second LAW of Thermodynamics.
> <<<

The purpose of science is to determine the truth. (Truth pre-existed its notice by humans.)

Eg. in the old days, scientists were RESPONSIBLE humans, they dealt with issues within their science, and tore down absurd theories, they applies the Four Laws of Thought and resolved any unresolved issue (LEM), they rejected any contradiction (LNC). The result being, lay people did not have to argue about an issue. Due to their grounding in Reality, in Objective Truth, opinions and consensus and citations were irrelevant. One either accepted objective truth and remained sane, or one rejected it and embraced insanity.. There is no argument to be had.

In these dark days, when the best of human filth is propagandised as “science”, the counter-point needs to be articulated.

With the implementation of Modernism in science, since 1911 (date according to my research thus far, Modernism as it destroyed Philosophy was late 18th century):
- Four Laws of Thought rejected
- Logic suppressed
- Composition & Causation (Cause & Effect) rejected
- the natural hierarchy rejected
- Atomicity rejected, fragments divorced from their context (the atom) and elevated
- limited to Materialism (the intellectual realm rejected)
- instead of ONE level of speculation BASED ON knowledge, speculation upon unproved speculation
--- speculation upon unproved speculation upon unproved speculation
----- speculation upon unproved speculation upon unproved speculation upon unproved speculation
- theories that keep changing (which in and of itself prove the theory false) and allowed to keep changing, in the fervent hope that if they change enough
--- Evolutionism is the most propagandised and thus the best example: it defies logic and science; not a single shred of proof in 170 years; it lies in denial of evidence that proves it false; and the theory keep changing
- introduction of relativism; subjectivism;
--- as infamously promoted by the worlds greatest plagiarist, alberto sow-sucking einstein
--- whose theories (other than the ones he stole) have all broken down, due to his plugging in false numbers that he “believed in”, instead of properly determined scientific numbers
- thus the focus has moved, the purpose has been corrupted,
- the purpose is now to PRODUCE the “truth”
--- which by definition means that it is not truth but fiction contrived by man
- it is pseudo-science; anti-science; Modern “science” because it contradicts established science
- mathematics (formalism; a language) promoted as a “science”, as a “language of the universe”
- reframing truth as “claims”; Straw Man arguments against Science
- since there is no objective truth, any and all issues can be argued, ad infinitum, without resolution
- citations and consensus has become the measure of probability
- totally irresponsible for adult humans
- nothing less than insanity

In this field, as evidenced, concerted suppression of the truth, the /RM/, and massive propaganda elevating 1960’s Record Filing Systems as “relational”. Anything the freaks did not invent (even FORTY YEARS after it was implemented by scientists) is ignored; denied, so that they can “invent” it from scratch.

Whereas Science is characterised by Objective Truth; Reality, Modern “science” is characterised by its performers, its propagandists. Here is a perfect example of a two performers, one a heavily marketed “scientist” in conversation with another performer. This is the same freaky idiot that promotes Newton’s Laws as precisely what it is not. The diminution of Science, the elevation of idiocy as “science”.

____ https://www.youtube.com/watch?v=VbUoaBJd2sA

Hence I reject it outright. As evidenced in my posts.

If requested, I can articulate that further, or provide further detail; evidence; etc. As if there is not enough evidence in these threads.

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<sdr2hf$1olo$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=201&group=comp.databases.theory#201

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!x1oN0PD4g7Q187dP8QyX1w.user.46.165.242.75.POSTED!not-for-mail
From: nic...@nohost.org (Nicola)
Newsgroups: comp.databases.theory
Subject: Re: Checkpoint & Consolidated Doc
Date: Wed, 28 Jul 2021 07:55:27 -0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <sdr2hf$1olo$1@gioia.aioe.org>
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com>
<24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com>
<7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com>
<3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com>
<17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com>
<8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com>
<29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com>
<47ee4839-9974-4841-8b49-6b86e32eab0en@googlegroups.com>
<d1daf4a4-06ce-439f-af90-23dc7d01c772n@googlegroups.com>
<99467d73-1fce-47d9-960b-1ff0a1e0bc85n@googlegroups.com>
Injection-Info: gioia.aioe.org; logging-data="58040"; posting-host="x1oN0PD4g7Q187dP8QyX1w.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Nicola - Wed, 28 Jul 2021 07:55 UTC

On 2021-07-27, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:
>> On Tuesday, 27 July 2021 at 20:59:24 UTC+10, Daniel wrote:
>> If you're using a clock-based timestamp such as DATETIME, instead of
>> a server-wide monotonic integer (which is what the Microsoft
>> ROWVERSION is), what do you do to handle the possibility of clock
>> skew on the database server?
>
> What skew ??? Where is this skew ???

How do you handle a situation in which the system's clock starts
reporting an inexact time? It may not happen frequently, but it does
happen (say, the NTP daemon crashes, or gets the wrong time for some
reason). Or, if you have two servers writing data into the database,
their clocks might be off, say, by a few seconds.

Nicola

Re: Checkpoint & Consolidated Doc

<0a0bef76-a9b1-4840-9150-bd544e8d8d72n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=202&group=comp.databases.theory#202

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a37:9b44:: with SMTP id d65mr25300616qke.71.1627468571437;
Wed, 28 Jul 2021 03:36:11 -0700 (PDT)
X-Received: by 2002:a05:6808:2089:: with SMTP id s9mr18324173oiw.156.1627468571213;
Wed, 28 Jul 2021 03:36:11 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Wed, 28 Jul 2021 03:36:10 -0700 (PDT)
In-Reply-To: <sdr2hf$1olo$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.138; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.138
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com> <47ee4839-9974-4841-8b49-6b86e32eab0en@googlegroups.com>
<d1daf4a4-06ce-439f-af90-23dc7d01c772n@googlegroups.com> <99467d73-1fce-47d9-960b-1ff0a1e0bc85n@googlegroups.com>
<sdr2hf$1olo$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0a0bef76-a9b1-4840-9150-bd544e8d8d72n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Wed, 28 Jul 2021 10:36:11 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 154
 by: Derek Ignatius Asirv - Wed, 28 Jul 2021 10:36 UTC

> On Wednesday, 28 July 2021 at 17:55:29 UTC+10, Nicola wrote:
> > On 2021-07-27, Derek Ignatius Asirvadem Derek wrote:
> >> On Tuesday, 27 July 2021 at 20:59:24 UTC+10, Daniel wrote:

Nicola

I will change the sequence of your questions, in order to provide a normalised answer.

> >> If you're using a clock-based timestamp such as DATETIME, instead of
> >> a server-wide monotonic integer (which is what the Microsoft
> >> ROWVERSION is), what do you do to handle the possibility of clock
> >> skew on the database server?
> >
> > What skew ??? Where is this skew ???
>
> How do you handle a situation in which the system's clock starts
> reporting an inexact time?

I do not understand why this is relevant, or why an SQL developer (using a database, plus a good OLTP strategy, even if not perfect or standard-compliant) should concern themselves about it.

We are setting the row TimeStamp (Datatype DATETIME, millisec resolution, not microsec) from the SQL Server via GETDATE().

Whatever time problems occur, they occur in the server, and it has to be dealt with in the server. There is nothing that the SQL developer can do, either beforehand (I expect you think this somehow affects the Transaction Template), or after.

If you are that concerned about it, use a VersionNo (Datatype INT) instead. Set it to 1 on INSERT, set it to VersionNo + 1 on UPDATE.

----
> Or, if you have two servers writing data into the database,
> their clocks might be off, say, by a few seconds.

1. Those are issues for whoever writes the server to figure out, and to secure. Again, it has nothing to do with the database or the SQL developer, they can’t do anything about it.

2. Unless you are abusing the term “server”, there is no such thing as “two servers writing data to the database”.

3. In mickey mouse freeware (and Oracle) which are not servers by any stretch of the imagination (ok, ok, academics have more stretched imagination capability than normal folk), there is no server, instead they have hundreds of programs running as a herd (inspect the following link), on a machine that is treated as a server (which needs to be 100 to 1,000 times bigger and more powerful than a machine that is used for a commercial SQL Platform). The use of the term “server” is false, fraudulent, disgusting.

Yeah, sure, in mickey mouse land, the “server” is not a server, it is not SQL compliant, and it does not provide any of the consistency or security (here we mean execution and processing consistency and security) that is provided by commercial SQL Platforms. You will be writing a hell of a lot more code than in SQL, and you will have to take care of things manually (such as multiple manual lock strategies, and now this “time skew”), that are done automatically in SQL.

4. It is very sad, that such burdens, which are the domain of the “server” developer, are foisted onto the SQL developer. But it must be noted that that is the hallmark of the insane: they are not responsible (by definition, the premise of the Mental Health Act), and they impose their problems on normal humans, who can be responsible.

5. Any code you write for a PooPooPooGross anti-server, 100% of it is not SQL, it cannot be ported to an SQL Platform. And when you move to one, all that low-level code will be eliminated.

You are best advised to stay away from such filth. You get what you pay for.

Link
Got to this page:
__ https://www.softwaregems.com.au/Documents/Sybase%20GEM%20Documents/
Read the section on *Database Server Architecture*
Download the *Oracle & Freeware vs Sybase ASE* PDF.
Just four pages with pretty pictures.

----
> It may not happen frequently, but it does
> happen (say, the NTP daemon crashes, or gets the wrong time for some
> reason).

Well, if you are using NTP, that means you have “distributed” mickey mouse processing (as distinct from genuine distributed processing). For the purpose of distributing the task or load, and it again is fraudulently promoted as “parallel processing”. Nothing could be further than the truth, that is not parallel processing. That is just using a [machine] server farm, instead of a single [machine] server, because (a) your mickey mouse program herd can’t handle the query on a single [machine], and (b) the [machine] server cannot be upgraded any further.

Doing that for a database server (real or mickey mouse) is hysterically stupid (it is fine for number crunching and bitcoin mining). It is not architecture, but mere resource addition. And then you CREATE a whole mess of new problems that a database server does not have: synchronisation; shared memory objects (oops, you don’t have even the notion of shared memory); distributed lock contention; massive contention on the single transaction log file ... the list is endless.

So they take their non-architecture to a “whole new level”, non-architecture squared.

Even if the freaks did all that stupid stuff, it should be done such that the SQL developer and DBA have nothing to do, nothing to concern themselves with. It is a program herd problem that only the program herd can deal with.

Again, foisting that burden onto the developer is criminal insanity, completely irresponsible. But aaaah, the academics think that that is normal.

You are best advised to stay away from such filth. You get what you pay for.

In case you do not understand, Sybase; MS; DB2 are genuine servers, with a server architecture, offering genuine parallel processing, using chip threads for load distribution. They execute as a SINGLE PROCESS on unix. There is no distributed processing ala multiple machine, because doing that for a database server is hysterically stupid, and there is no problem at all executing on a tiny machine, which can be upgraded as required (100 to 1,000 times smaller than that demanded by PusGres or Orable). (Sybase does have a Cluster Edition, but that has a different purpose, not relevant here).

>>>>
Hell, I run several Sybase servers that host thousands of client connections, with just 12 chip threads. And I am definitely not the only one.

I am getting the consistent impression that you do not bother to read the links I give you. I do not ask you to read anything that is not completely relevant. I gave you this link a couple of times.
__ https://www.softwaregems.com.au/Documents/Article/Sysmon%20Processor/Sysmon%20Processor%20Eg%20Date%20Delta.pdf
Read it. Examine it. Ask questions. Just the short *Selection* section at the top. On this machine, we hosted hundreds of connections, on just four engines (four unix processes [that was 2013, using Process Architecture, before the advent of Thread Architecture] ). Using:
- Frame 56%
- Unix/CPU User 19%
- Sybase (four processes) 20%
--- That is, Sybase used 20% of 19% machine power.
<<<<

Gear up on Sybase ASE and find out what a real server is; what real parallelism is. You can spend all the time you save (more than half of what you will spend on a PeePooPeeGress implementation) doing something useful, instead of struggling with low-level issues that is not your problem.

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<72f2500f-343e-4111-bc88-fa9a6a09ba4cn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=203&group=comp.databases.theory#203

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:620a:4089:: with SMTP id f9mr12931731qko.441.1627869698668;
Sun, 01 Aug 2021 19:01:38 -0700 (PDT)
X-Received: by 2002:a05:6830:712:: with SMTP id y18mr10339484ots.99.1627869698423;
Sun, 01 Aug 2021 19:01:38 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Sun, 1 Aug 2021 19:01:38 -0700 (PDT)
In-Reply-To: <99467d73-1fce-47d9-960b-1ff0a1e0bc85n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.146; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.146
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<b91e0eb2-7821-4135-bb6f-bd51777e9897n@googlegroups.com> <01066d90-641f-4875-81e4-213422e0919bn@googlegroups.com>
<6b2e7ee0-b550-4534-904d-ebc3fc7818adn@googlegroups.com> <08e726e7-1066-45d4-a7da-838c34c69c46n@googlegroups.com>
<sbnug5$sib$1@gioia.aioe.org> <4b680c9a-bc22-479d-9bb9-04f2d6907b2en@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com> <47ee4839-9974-4841-8b49-6b86e32eab0en@googlegroups.com>
<d1daf4a4-06ce-439f-af90-23dc7d01c772n@googlegroups.com> <99467d73-1fce-47d9-960b-1ff0a1e0bc85n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <72f2500f-343e-4111-bc88-fa9a6a09ba4cn@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Mon, 02 Aug 2021 02:01:38 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Mon, 2 Aug 2021 02:01 UTC

Guys and dolls

Can we please get some progress here. We have not finished, and the Template is not complete.

Recap for the exact position that we are at.

> On Wednesday, 28 July 2021 at 08:03:50 UTC+10, Derek Ignatius Asirvadem wrote:
> > On Tuesday, 27 July 2021 at 20:59:24 UTC+10, Daniel wrote:
> >
> > >We need to understand it forwards. His Transaction completed and it persists ... and therefore he has confidence in the system. XOR his Transaction completed, but it did not persist ... and therefore he has no confidence in the system. Transaction Sanity/p4.
> >
> > > Was the Transaction Durable or not ?
> > No. Neither the User 1 or User 2 transactions make use of the timestamp based concurrency control.
> Yes, that is the back end, or developer’s understanding.
>
> What is in the user’s mind, how does he perceive it ?

What is in the user’s mind, how does he perceive it ?

Pages 4 and 5 in the Transaction Sanity doc.

> > > I am provoking a thought process in your mind. Focus on *BASIS*. Here you have to get rid of any MV-non-CC or “MVCC” notions because they are bankrupt. Think in terms of Reality, an online shared database that contains a single version of any single fact.
>
> > So what you're getting at, especially with the mention of paper-based, is: It's inconceivable that you could inadvertently clobber someone else's change to that single piece of paper without being cognisant of that. After all, they've written on the paper and put it back, and then you've picked it up and looked at it. Obviously being a single piece of paper, without duplicates, access to the piece of paper involves queuing up for it and waiting your turn.
> Yes. Excellent parallels drawn. Keep going.
> - In the paper system, the person (first-up in the queue) would have be cognisant.
> - think: a library card system, arranged in 200 little drawers for convenience of physical access by many people
> - In the automated system, the program has to be cognisant.
> - In the paper system, the person (first-up in the queue for a particular card) has an idea of its data currency based on something, so that when he returns (with the intended update), he would be cognisant that the card has changed.
> - In the automated system, the program has to do that.

What is the *BASIS* for confidence that an update can be performed on a row, or library card ?

I teach this stuff, I cannot give you the Lecture Notes or the SG OLTP Template, but I have given you a Transaction Sanity doc, so that at least this thread and the issues herein can be fully understood, that it can progress to closure; the Template can be completed. You need to have an illumination, which means progressing your own thinking, not merely being told. Which is why I am provoking thought.

When you have that illumination, you will (a) realise the principle of an OLTP system, and (b) therefore, how false and incorrect the notion of multiple offline versions is.

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<195b9b1a-d069-48de-8ba9-a02826e9f900n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=204&group=comp.databases.theory#204

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ac8:688b:: with SMTP id m11mr12205128qtq.122.1627870752660;
Sun, 01 Aug 2021 19:19:12 -0700 (PDT)
X-Received: by 2002:aca:7550:: with SMTP id q77mr8380179oic.5.1627870752460;
Sun, 01 Aug 2021 19:19:12 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Sun, 1 Aug 2021 19:19:12 -0700 (PDT)
In-Reply-To: <sdor6j$1vsl$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.146; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.146
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com> <sdor6j$1vsl$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <195b9b1a-d069-48de-8ba9-a02826e9f900n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Mon, 02 Aug 2021 02:19:12 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Mon, 2 Aug 2021 02:19 UTC

Nicola

> On Tuesday, 27 July 2021 at 21:37:57 UTC+10, Nicola wrote:
>
> Hence, I am eager to hear what you have to say
> about it.

Please feel free. Ask a specific question.

> Even got SQL Server and Sybase installed

Well, I am certainly not going to dissuade you from learning about the real world; about commercial SQL Platforms; what SQL really is; what ACID Transactions mean. Good on you, for taking one more step out of the academic isolation from the all that. On the contrary, I encourage you, as the first academic who is trying to close the chasm, of FORTY YEARS of isolation from the real world.

But that will take six, maybe twelve months. And that will be severely limited by the academic mindset, that you think you know SQL; ACID; commercial platforms; etc, which is pure perversity, as I have detailed and evidenced in many posts. So please learn those subjects with fresh mind, with an accurate disposition: that you do not know those subjects. Otherwise it would be like a prostitute trying to learn about chastity.

> ... to verify your claims
> :)

Well, if you enumerate even one or two of those declaration (that you re-frame as "claims"), which are not diminished by your re-framing, I can answer them at short notice, and refer you to manuals, etc. No need to wait six months, no need to download software and gear it up yourself. Please name the declarations that you have trouble accepting.

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<e57013d3-fce5-4c81-9b4c-ce0d41af49e6n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=205&group=comp.databases.theory#205

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ae9:ed05:: with SMTP id c5mr13431912qkg.24.1627880693863;
Sun, 01 Aug 2021 22:04:53 -0700 (PDT)
X-Received: by 2002:a05:6830:1d57:: with SMTP id p23mr10488605oth.55.1627880693634;
Sun, 01 Aug 2021 22:04:53 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Sun, 1 Aug 2021 22:04:53 -0700 (PDT)
In-Reply-To: <195b9b1a-d069-48de-8ba9-a02826e9f900n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.146; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.146
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com> <sdor6j$1vsl$1@gioia.aioe.org>
<195b9b1a-d069-48de-8ba9-a02826e9f900n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e57013d3-fce5-4c81-9b4c-ce0d41af49e6n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Mon, 02 Aug 2021 05:04:53 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Mon, 2 Aug 2021 05:04 UTC

Nicola

> On Monday, 2 August 2021 at 12:19:13 UTC+10, Derek Ignatius Asirvadem wrote:
> > On Tuesday, 27 July 2021 at 21:37:57 UTC+10, Nicola wrote:
>
> > ... to verify your claims
> > :)
>
> Well, if you enumerate even one or two of those declaration (that you re-frame as "claims")

Yes, of course that is dishonest. In case it needs to be said, I am not saying that you are consciously being dishonest. I am saying, that is standard academic practice, that you are schooled in. The classic method they use: re-frame a declaration as something that it is not, and then either burn it, a Straw Man of your own creation, or at the least diminish it.

Further, you take declarations and absolute statements very lightly, as re-framed "claims". Even your own. You do not have the self-respect, or respect for the science, that is required to treat them with respect, to obtain resolution. You do not correct your declarations (I won't call them "claims") when they are proved false. Eg. the Movie Title thread. Eg. the paper you wrote declaring that it could *NOT* be modelled using the /Relational Model/, that it could only be done by resorting to physical Record Ids ala the anti-Relational RM/T.

Cheers
Derek

Re: Checkpoint & Consolidated Doc

<443000f1-da17-4868-9cff-58a12a635383n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=206&group=comp.databases.theory#206

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ac8:73c9:: with SMTP id v9mr13878829qtp.214.1627907546349;
Mon, 02 Aug 2021 05:32:26 -0700 (PDT)
X-Received: by 2002:a9d:2f47:: with SMTP id h65mr11696503otb.299.1627907546066;
Mon, 02 Aug 2021 05:32:26 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Mon, 2 Aug 2021 05:32:25 -0700 (PDT)
In-Reply-To: <e57013d3-fce5-4c81-9b4c-ce0d41af49e6n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=193.119.51.108; posting-account=S056qgoAAAASvuIiqcdQPeaQ70w-ZkVa
NNTP-Posting-Host: 193.119.51.108
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com> <sdor6j$1vsl$1@gioia.aioe.org>
<195b9b1a-d069-48de-8ba9-a02826e9f900n@googlegroups.com> <e57013d3-fce5-4c81-9b4c-ce0d41af49e6n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <443000f1-da17-4868-9cff-58a12a635383n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: daniel.j...@gmail.com (Daniel Loth)
Injection-Date: Mon, 02 Aug 2021 12:32:26 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Daniel Loth - Mon, 2 Aug 2021 12:32 UTC

Hi Derek,

---

> Concerning clock skew

Nicola's reply about clock skew covers what I was getting at. Specifically, a clock moving backwards or forwards. Moving backwards means there is potential for you to see the same datetime twice.

You don't see it happen often, but every now and then it does. Oftentimes things like authentication services stop working because they're heavily reliant on relatively precise time keeping.

This is why I personally lean towards the SQL Server rowversion type mentioned.

Rowversion is notably just a synonym for 'timestamp' as you've described Sybase 4.2 as having. Another Microsoft-ism. In fact, you can still use the 'timestamp' data type when writing the table DDL and that'll work fine, though the 'timestamp' keyword is technically deprecated.

I think the deprecation is because Microsoft's 'timestamp' is not 'timestamp' in the ISO standard sense. In SQL Server, a non-null rowversion is equivalent to binary(8). A nullable rowversion is equivalent to varbinary(8).
To make sense of the number expressed as binary(8), you can cast it to a bigint. At that point it becomes useful for concurrency control in much the same way that UpdatedDtm is.

---

> Concerning durability and user perception

In the user's mind, you are right that their perception of the system is that it has not lived up to the guarantees of the ACID concept of durability. They won't recognise that it was written to disk for a fleeting moment before their changes were clobbered by a subsequent transaction.
They simply see the final outcome, which is that a subsequent user's actions have overwritten their own.

You also mentioned user training teaching users that they would expect to see their changes after performing a transaction, and teaching users that the durability property means that they can be confident that a reportedly committed transaction indicates that the changes made in their transaction will stick.

In the library card system, the basis for their confidence that they, and they alone, can update the physical card and return it to the drawer. And it's just one card, so their changes will be there when the next person takes it from the drawer.
And this is essentially what the lock management system does. It affords that mutually exclusive access to the library card.

Is that the basis you are asking for?

---

> Lost currency on page 5 in the Transaction Sanity document

I read this. Basically, the problem is that I load a screen with a number of fields on it. I grab a drink. I come back 10 minutes later, make a minor change, and click 'Save'. In doing so I've just wiped out the work of a colleague who made a lot of changes during my 10 minute absence because what happened to be on my screen was the old, not-current, data when I clicked 'Save'.

It needn't be such a protracted period of time of course. The same could happen in mere seconds.

Lost update protection prevents this.

---

> The template being unfinished

Is it unfinished due to the lack of lost update protection? Or is there something else missing?
As far as I can see, it's already doing a good job in terms of contention management.

I've posted a new GitHub Gist here: https://gist.github.com/DanielLoth/0599c2475368083acc9032d34f0919e1
This revision of the code contains lost update protection using the UpdatedDtm column in the Person table.

---

Cheers,
Dan

Re: Checkpoint & Consolidated Doc

<se9riv$395$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=207&group=comp.databases.theory#207

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!x1oN0PD4g7Q187dP8QyX1w.user.46.165.242.75.POSTED!not-for-mail
From: nic...@nohost.org (Nicola)
Newsgroups: comp.databases.theory
Subject: Re: Checkpoint & Consolidated Doc
Date: Mon, 2 Aug 2021 22:28:47 -0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <se9riv$395$1@gioia.aioe.org>
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com>
<7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com>
<3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com>
<17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com>
<8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com>
<29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com>
<47ee4839-9974-4841-8b49-6b86e32eab0en@googlegroups.com>
<d1daf4a4-06ce-439f-af90-23dc7d01c772n@googlegroups.com>
<99467d73-1fce-47d9-960b-1ff0a1e0bc85n@googlegroups.com>
<72f2500f-343e-4111-bc88-fa9a6a09ba4cn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="3365"; posting-host="x1oN0PD4g7Q187dP8QyX1w.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Nicola - Mon, 2 Aug 2021 22:28 UTC

On 2021-08-02, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:
> Can we please get some progress here. We have not finished, and the
> Template is not complete.
>
> Recap for the exact position that we are at.
>
>> On Wednesday, 28 July 2021 at 08:03:50 UTC+10, Derek Ignatius Asirvadem wrote:
>> > On Tuesday, 27 July 2021 at 20:59:24 UTC+10, Daniel wrote:
>> >
>> > >We need to understand it forwards. His Transaction completed and
>> > >it persists ... and therefore he has confidence in the system. XOR
>> > >his Transaction completed, but it did not persist ... and
>> > >therefore he has no confidence in the system. Transaction
>> > >Sanity/p4.
>> >
>> > > Was the Transaction Durable or not ?
>> > No. Neither the User 1 or User 2 transactions make use of the
>> > timestamp based concurrency control.
>> Yes, that is the back end, or developer’s understanding.
>>
>> What is in the user’s mind, how does he perceive it ?

> Pages 4 and 5 in the Transaction Sanity doc.

I'd say that there are two Logical Units of Work (LUW—I think the term
was used in CICS), one by User 1 and one by User 2. When updating
a value, each user will assume that the value they have replaced is the
one they had previously read (if the system lets the update go through).

Each LUW consists of more than one database transactions. I refer to
each SELECT statement in that example as a (read-only, database)
transaction. Hence, some state must be maintained between database
transactions, to make each LUW meet the user's expectations. In this
case, the state is the pair (@CreditRatingCode,@BirthPlace), i.e., the
information initially retrieved by each user. Then, both TweedleDumb and
TweedleDumber should check that such values have not been changed since
the corresponding previous SELECT, and do so before updating the record.

Rather than checking the values directly, a SELECT could also read
a version number of the retrieved record and pass it to TweedleDumb
(resp., TweedleDumber), which would check that the version number still
matches (by re-reading it), in which case it would update the record and
increase the version number.

Nicola

Re: Checkpoint & Consolidated Doc

<seasvr$12ao$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=208&group=comp.databases.theory#208

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!x1oN0PD4g7Q187dP8QyX1w.user.46.165.242.75.POSTED!not-for-mail
From: nic...@nohost.org (Nicola)
Newsgroups: comp.databases.theory
Subject: Re: Checkpoint & Consolidated Doc
Date: Tue, 3 Aug 2021 07:58:51 -0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <seasvr$12ao$1@gioia.aioe.org>
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com>
<7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com>
<3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com>
<17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com>
<8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com>
<29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com>
<47ee4839-9974-4841-8b49-6b86e32eab0en@googlegroups.com>
<d1daf4a4-06ce-439f-af90-23dc7d01c772n@googlegroups.com>
<99467d73-1fce-47d9-960b-1ff0a1e0bc85n@googlegroups.com>
<72f2500f-343e-4111-bc88-fa9a6a09ba4cn@googlegroups.com>
<se9riv$395$1@gioia.aioe.org>
Injection-Info: gioia.aioe.org; logging-data="35160"; posting-host="x1oN0PD4g7Q187dP8QyX1w.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Nicola - Tue, 3 Aug 2021 07:58 UTC

Daniel summarized Derek's approach as follows:

>Derek in particular described his approach and in doing so expressed
>two principles:
>
>1. Only acquire exclusive (write) locks if the transaction will
>potentially succeed.
>
>2. Never acquire exclusive locks if embarking on the transaction is
>futile (or put another way, don't start what you absolutely cannot
>finish).
>
>Consistent with those principles, the ideal was described as:
>
>1. A validate block - Where we 'look before we leap' (to borrow that
>expression). In this block we are reading only. We can use the READ
>COMMITTED isolation level, thereby acquiring and releasing shared locks
>in quick succession. No shared locks are held after the conclusion of
>the statement (i.e., the select query in this case).
>
>2. A transaction block - Where we check again and, if the conditions
>are still right (i.e., other users might have changed the data), we can
>proceed to do our work and then commit the transaction. In this block
>we acquire write locks, and these locks are held for the remainder of
>the transaction (until we commit or rollback).

Exercise 18.11 (and its solution) from Silberschatz's "Database System
Concepts" seems relevant:

https://www.db-book.com/db7/Practice-Exercises/PDF-practice-solu-dir/18.pdf

Nicola

Re: Checkpoint & Consolidated Doc

<33000858-68f6-4b2c-b8b7-9d055253a9b1n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=209&group=comp.databases.theory#209

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:6214:e62:: with SMTP id jz2mr20697676qvb.21.1627986376237;
Tue, 03 Aug 2021 03:26:16 -0700 (PDT)
X-Received: by 2002:a9d:6c1:: with SMTP id 59mr14418867otx.318.1627986375955;
Tue, 03 Aug 2021 03:26:15 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Tue, 3 Aug 2021 03:26:15 -0700 (PDT)
In-Reply-To: <443000f1-da17-4868-9cff-58a12a635383n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=49.195.58.225; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 49.195.58.225
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<sbs1ar$183a$1@gioia.aioe.org> <6d5f8e6d-6b92-486e-abf6-427881b81992n@googlegroups.com>
<sbsm2l$1kur$1@gioia.aioe.org> <0e636dee-beb0-4ad5-87f1-885f2bc43b16n@googlegroups.com>
<06d37a97-3a04-4d6f-8547-0a9d45d92009n@googlegroups.com> <24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com>
<163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com> <7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com>
<ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com> <3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com>
<7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com> <17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com>
<86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com> <8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com>
<f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com> <29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com>
<69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com> <sdor6j$1vsl$1@gioia.aioe.org>
<195b9b1a-d069-48de-8ba9-a02826e9f900n@googlegroups.com> <e57013d3-fce5-4c81-9b4c-ce0d41af49e6n@googlegroups.com>
<443000f1-da17-4868-9cff-58a12a635383n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <33000858-68f6-4b2c-b8b7-9d055253a9b1n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Tue, 03 Aug 2021 10:26:16 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Tue, 3 Aug 2021 10:26 UTC

Dan

Thanks for your response.

> On Monday, 2 August 2021 at 22:32:27 UTC+10, Daniel Loth wrote:
>
> > Concerning clock skew
>
> Nicola's reply about clock skew covers what I was getting at. Specifically, a clock moving backwards or forwards. Moving backwards means there is potential for you to see the same datetime twice.
>
> You don't see it happen often, but every now and then it does. Oftentimes things like authentication services stop working because they're heavily reliant on relatively precise time keeping.
>
> This is why I personally lean towards the SQL Server rowversion type mentioned.
>
> Rowversion is notably just a synonym for 'timestamp' as you've described Sybase 4.2 as having. Another Microsoft-ism. In fact, you can still use the 'timestamp' data type when writing the table DDL and that'll work fine, though the 'timestamp' keyword is technically deprecated.
>
> I think the deprecation is because Microsoft's 'timestamp' is not 'timestamp' in the ISO standard sense. In SQL Server, a non-null rowversion is equivalent to binary(8). A nullable rowversion is equivalent to varbinary(8).
> To make sense of the number expressed as binary(8), you can cast it to a bigint. At that point it becomes useful for concurrency control in much the same way that UpdatedDtm is.

Yes.

TIMESTAMP and ROWVERSION is the database timestamp from the internal DBTABLE. It is the no of writes to the database, asequential number that already exists (and thus does not have to be created and maintaiined ... maintenance of such a number [eg. record ID] is a significant overhead and contention issue, to be avoided).

For inspection, BINARY() obtains nothing. (BINARY “works”, in the sense that it allows inspection of any column.)

BIGINT is correct, and it is readable, SELECT-able. There you can see the incrementing [database-wide] value.

If there are no NULLs in the database, you will not see VAR*anything, all columns will be fixed-length.

The way Sybase and MS store a NULL is, by declaring the length of the column to be zero. In order to get that length stored, it has to be a VAR column (fixed length columns do not need such a definition). That adds 4 bytes to the column [position & length].

Clock skew is not an issue, because it is in the server, and we set the TimeStamp from the server GETDATE(). There never is a difference between the Time in the client vs the Time in the server, we work on server Time only.

If clock skew affects the server, then fix the server. We do not have to take responsibility in the database or app for a server fault.

If you have an el cheapo server that suffers such things, use a VersionNo instead. That is an actual row version number. (MS ROWVERSION is a false label.) Set it to 1 on INSERT, increment it on UPDATE.

> ---
>
> > Concerning durability and user perception
>
> In the user's mind, you are right that their perception of the system is that it has not lived up to the guarantees of the ACID concept of durability. They won't recognise that it was written to disk for a fleeting moment before their changes were clobbered by a subsequent transaction.
> They simply see the final outcome, which is that a subsequent user's actions have overwritten their own.

So they do know that their Transaction was not [D]urable. (Unlike academics and novice developers, I have never had to explain to a user that [D]urable does not mean durable but some private definition.)

> You also mentioned user training teaching users that they would expect to see their changes after performing a transaction, and teaching users that the durability property means that they can be confident that a reportedly committed transaction indicates that the changes made in their transaction will stick.

Yes, that is what [D]urable in ACID means. Due to the pig poop that academics write about, 95% of the people out there think that [D]urable is delivered by the server or herd of programs, they do not understand that it applies to Transaction code, they know nothing of Lost Update, or of Optimistic Locking. As evidenced here.

> In the library card system, the basis for their confidence that they, and they alone, can update the physical card and return it to the drawer. And it's just one card, so their changes will be there when the next person takes it from the drawer.
> And this is essentially what the lock management system does. It affords that mutually exclusive access to the library card.

[We are using the library card example to understand a paper-based system.)

Now that is a rigid library card system, there is only one version of each card, and it is manually removed from the card drawer for the duration of the change. Which means, other users queue up, waiting for the card to be returned, before they can use it. No lock manager is required. It becomes inadequate when the number of users contend over a fixed set of cards, the queues grow long for popular books (cards).

That is not what I meant. The advanced use of the library card system allows users to read the cards without removing them (eg. answering a call “do you have /Dr Who/ in the library ?”), and only remove the card when they need to update it (lend the book). So they inspect a card; record the TimeStamp that is on the card; go back to their other work. If and when they need to update the card
- they try to fetch it
- If the TimeStamp has changed, they know the info that they used is out-of-date, and they have to grab the new info from the card.
This allows substantially more users to contend over the same set of library cards, ie. high concurrency.

> Is that the basis you are asking for?

No.

You have all the mechanics, unfortunately from my 11-year-old TTM post, but not the illumination. I won’t labour it any longer.

The basis is the TimeStamp on the card, on the row in the database. The basis for any action:
- inspection followed by some work,
- or a Transaction,
- physical in the library card example, or logical in a row in the database
is the currency of the card or row. The TimeStamp.

The Lost Update happens because they did not observe the TimeStamp, and did not check before the update.

The Lost Currency happens because they did not observe the TimeStamp, and did not check before the update.

The Naïve Solution
- fixes the problem without understanding
- but ensures the system is high contention; low concurrency; lock-bound

> ---
>
> > Lost currency on page 5 in the Transaction Sanity document
>
> I read this. Basically, the problem is that I load a screen with a number of fields on it. I grab a drink. I come back 10 minutes later, make a minor change, and click 'Save'. In doing so I've just wiped out the work of a colleague who made a lot of changes during my 10 minute absence because what happened to be on my screen was the old, not-current, data when I clicked 'Save'.

At the point at which you hit ‘Save’, the *BASIS* for confidence that your Transaction would succeed was ???

Answer: it is dependent on the Currency of the data that you previously retrieved. Which currency was lost the moment you retrieved it. Because it is an online shared database. That is used by other online users. Who are updating the online shared database, all the time.

The key point to be understood here (the illumination) is the currency of the data. That it changes. That the currency is IN the data. That the currency must be stored as a TimeStamp in the row.

----

Now if you understand this deeply, you will understand that the notion of grabbing a row, AS A VERSION, and holding it, in your safe space, is hysterically stupid. Because the moment you grab the row, the version you hold is obsolete. It is a private offline version. It breaks the first principle of an online shared database, and [schizophrenically, in denial of reality] pretends that the obsolete version is something that can be relied upon.

Now you have learned precisely why, that it is not the version, or TimeStamp on the version (when the version was grabbed), that is relevant, but the TimeStamp on the row when the version was grabbed. The former is yet again, subjective, self-centred stupidity, AND in denial of the fact that the database is objective truth, a single version of the truth. The latter is in formal recognition that the database is the single version of the truth AND that it is shared, AND that the sharing is sociable, affording high concurrency.

Which is why “MVCC” can never work.

In order to make it work at all, they have to recognise that Stonebraker lied; lied; lied, their mantra is false; false; false, there is no Concurrency Control in “MVCC”, it is MV-non-CC, and they have to add a Lock Manager for Concurrency Control. Orable; MySql; PissGriss, all have one. MySQL is the best, because it affords logical locks that do not interfere with its Lock Manager, PissGriss is the worst because it is a horrible implementation (10,000 cultists spread across the planet) and it allows user-level lock in its Lock Managler, thereby guaranteeing conflicts; deadly embraces; and more lock contention, the precise thing that it alleges to solve. The level of dishonesty is criminal.

Further, MV-non-CC incurs a huge overhead, that of maintaining all those multiple fantasy versions, which it does all across the entire storage range of pages.

Anyone with half a brain would realise that since a Lock Manager fixes the problem, and it is essential, gee whiz, we can eliminate the MV-non-CC fantasy altogether. But no, that would mean the academics have half a brain, they would have to admit the MV-non-CC is an abject failure, both in principle and in implementation. Instead, they double down on the insanity that has been proved insanity, and they go for more locking, more layers of locking, more types of locks (you gotta love their darling “predicate locks”). They hope and pray to their deities, that their mountain of pig poop that has not worked in FORTY YEARS, will somehow work if they sacrifice their children to it.


Click here to read the complete article
Re: Checkpoint & Consolidated Doc

<8aba669d-94ec-4154-a0c2-9fe7045f17e1n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=210&group=comp.databases.theory#210

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ac8:6141:: with SMTP id d1mr2567187qtm.143.1627990172602;
Tue, 03 Aug 2021 04:29:32 -0700 (PDT)
X-Received: by 2002:aca:1111:: with SMTP id 17mr2740871oir.53.1627990172380;
Tue, 03 Aug 2021 04:29:32 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Tue, 3 Aug 2021 04:29:32 -0700 (PDT)
In-Reply-To: <se9riv$395$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=49.195.58.225; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 49.195.58.225
References: <1b40677e-3da3-41b7-b9b1-9c9aeca9f6f0n@googlegroups.com>
<24ac119d-8676-408c-a5c0-7f5ca5e21acen@googlegroups.com> <163b34e9-f4e3-4692-a661-861dc617a8aan@googlegroups.com>
<7497ea5c-fe09-48b4-af8e-e0243bbe89e1n@googlegroups.com> <ddfbe441-fe6f-415a-8741-eab1727d260bn@googlegroups.com>
<3aeab17e-aba3-4e36-aa27-bbb7c5d449d5n@googlegroups.com> <7816cb0b-8bac-4278-8e9e-02d1389296c1n@googlegroups.com>
<17658086-31e5-47eb-be7a-35bb5c8257aan@googlegroups.com> <86b51124-9575-4af4-b9a0-31d9a2c6a2b1n@googlegroups.com>
<8c79b4d5-df95-4924-bf2a-779f3631acb7n@googlegroups.com> <f5155373-8b5b-4eba-9ed7-bdd0e2e2ede0n@googlegroups.com>
<29b1899c-1492-4bd4-992f-a6900e83f8a2n@googlegroups.com> <69d3ee5d-2b1f-48ec-842d-b531d22a5ecfn@googlegroups.com>
<47ee4839-9974-4841-8b49-6b86e32eab0en@googlegroups.com> <d1daf4a4-06ce-439f-af90-23dc7d01c772n@googlegroups.com>
<99467d73-1fce-47d9-960b-1ff0a1e0bc85n@googlegroups.com> <72f2500f-343e-4111-bc88-fa9a6a09ba4cn@googlegroups.com>
<se9riv$395$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8aba669d-94ec-4154-a0c2-9fe7045f17e1n@googlegroups.com>
Subject: Re: Checkpoint & Consolidated Doc
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Tue, 03 Aug 2021 11:29:32 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Tue, 3 Aug 2021 11:29 UTC

> On Tuesday, 3 August 2021 at 08:28:49 UTC+10, Nicola wrote:
> > On 2021-08-02, Derek Ignatius Asirvadem wrote:
> > Can we please get some progress here. We have not finished, and the
> > Template is not complete.
> >
> > Recap for the exact position that we are at.
> >
> >> On Wednesday, 28 July 2021 at 08:03:50 UTC+10, Derek Ignatius Asirvadem wrote:
> >> > On Tuesday, 27 July 2021 at 20:59:24 UTC+10, Daniel wrote:
> >> >
> >> > >We need to understand it forwards. His Transaction completed and
> >> > >it persists ... and therefore he has confidence in the system. XOR
> >> > >his Transaction completed, but it did not persist ... and
> >> > >therefore he has no confidence in the system. Transaction
> >> > >Sanity/p4.
> >> >
> >> > > Was the Transaction Durable or not ?
> >> > No. Neither the User 1 or User 2 transactions make use of the
> >> > timestamp based concurrency control.
> >> Yes, that is the back end, or developer’s understanding.
> >>
> >> What is in the user’s mind, how does he perceive it ?
> > Pages 4 and 5 in the Transaction Sanity doc.
> I'd say that there are two Logical Units of Work (LUW—I think the term
> was used in CICS), one by User 1 and one by User 2. When updating
> a value, each user will assume that the value they have replaced is the
> one they had previously read (if the system lets the update go through).
>
> Each LUW consists of more than one database transactions. I refer to
> each SELECT statement in that example as a (read-only, database)
> transaction.

No. That is not a Transaction. You are still holding onto an incorrect notion that non-transactions are somehow Transactions. That contradicts (a) reality, (b) ACID, (c) SQL ACID compliance. If you keep calling a chichuahua a tiger, you will remain confused. Yes, I know, that is the PissGress mindest, their totally incorrect way of handling their offline versions; their additional 2PL locking, and for that they have redefined "transaction" .... they are always in some hysterically stupid "transaction" mode. It is false.

> Hence, some state must be maintained between database
> transactions, to make each LUW meet the user's expectations. In this
> case, the state is the pair (@CreditRatingCode,@BirthPlace), i.e., the
> information initially retrieved by each user. Then, both TweedleDumb and
> TweedleDumber should check that such values have not been changed since
> the corresponding previous SELECT, and do so before updating the record.
>
> Rather than checking the values directly, a SELECT could also read
> a version number of the retrieved record and pass it to TweedleDumb
> (resp., TweedleDumber), which would check that the version number still
> matches (by re-reading it), in which case it would update the record and
> increase the version number.

Yes.

One correction. LUW was the original CICS term, and it is still used in IBM/DB2. But it means Transaction, not PoopDePoopGres "transaction", not whatever you reframe it to mean. LUW means a single database Transaction, controlled according to ACID.

Cheers
Derek

Pages:1234
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor