On Monday, 14 June 2021 at 01:13:54 UTC+10, Nicola wrote:
Note that one should be used to that [DELETE+INSERT instead of UPDATE] because UPDATE any Key component
is not permitted, it must be DELETE+INSERT, in a Transaction of
course, that moves the entire hierarchy belonging to the Key.
That is because in your experience, cascading updates (UPDATE ...
CASCADE), are inefficient, right?
Theoreticians in this space, in their total abdication of responsibility, say that the server is a black box, and that they should not concern themselves with *ANY* implementation concerns. That is like saying the engineer of the car should not concern
From this post:
Also this post:
I'd like to do some benchmarks.
So think that out. Write an ACID Transaction (no I am not being
silly, I realise you can’t on your non-SQL platform, so you have to
think in SQL terms, for an SQL platform). A stored proc, that:
- navigates the *levels* of the Tree,
- and loops,
- executing max 100 INSERTs per BEGIN::COMMIT for the new Key,
- then executing max 100 DELETEs per BEGIN::COMMIT for the old Key.
On Tuesday, 15 June 2021 at 03:39:09 UTC+10, Nicola wrote:
On 2021-06-14, Derek Ignatius Asirvadem wrote:Let me call this T1...
So think that out. Write an ACID Transaction (no I am not being
silly, I realise you can’t on your non-SQL platform, so you have to think in SQL terms, for an SQL platform). A stored proc, that:
- navigates the *levels* of the Tree,
- and loops,
- executing max 100 INSERTs per BEGIN::COMMIT for the new Key,
- then executing max 100 DELETEs per BEGIN::COMMIT for the old Key....and this T2.
Why is the state after T1 has committed and before T2 starts considered valid? Wouldn't a query performed between T1 and T2 get an inconsistent
view of the data?
Another question: if T1 requires 200 INSERTs instead of 100, you would
split it in two. Again, how can you consider the intermediate state
(after the first 100 INSERTs, but before the remaining ones) valid?
On 2021-06-14, Derek Ignatius Asirvadem wrote:
1.b So the example "business transaction" would be converted into a batch job that runs in a loop and executes six million OLTP Standard-compliant single-row transactions.
On Tuesday, 15 June 2021 at 08:08:25 UTC+10, Derek Ignatius Asirvadem wrote:
On Tuesday, 15 June 2021 at 03:39:09 UTC+10, Nicola wrote:
On 2021-06-14, Derek Ignatius Asirvadem wrote:
So think that out. Write an ACID Transaction (no I am not being
silly, I realise you can’t on your non-SQL platform, so you have to think in SQL terms, for an SQL platform).
Write an ACID Transaction
with Logical Atom; non-compliant db = does not have Logical Atom), here we are moving an entire tree, of many levels, therefore State in the ACID sense will not apply.A stored proc, that:
- navigates the *levels* of the Tree,
- and loops,
- executing max 100 INSERTs per BEGIN::COMMIT for the new Key,
Let me call this T1...
- then executing max 100 DELETEs per BEGIN::COMMIT for the old Key.
...and this T2.
We can call it T1; T2, but we don’t want to confuse that with a normal ACID Transaction T1; T2, because it is not, it is a Batch Transaction. Whereas in ACID, we are dealing with {Add|Drop|Mod} a logical Atom of data (RM-compliant db = coincident
We may be better off calling it B1; B2.
On Monday, 14 June 2021 at 14:35:13 UTC+10, Derek Ignatius Asirvadem wrote:with little idea re what is happening under the covers.
On Monday, 14 June 2021 at 01:13:54 UTC+10, Nicola wrote:
I'd like to do some benchmarks.
Great idea. Excellent ...
*Benchmark* strongly implies an ability to monitor the server, all metrics that pertain to performance (in general), and the particular metrics that pertain to the particular benchmark. Freeware has no such thing, so you will be working in the dark,
For contrast, take a glimpse of what is available in commercial SQLs.
0. Monitoring products
Additional licence fee, not shown. Feel free to search the internet.
1. Raw Stats: text, various forms. Free.
Voluminous, not shown. Can be ascertained from the following [which are summaries].
2. Raw Stats Formatted, especially for various types of comparison.
__ https://www.softwaregems.com.au/Documents/Article/Sysmon%20Processor/Sysmon%20Processor%20Eg%20Date%20Delta.pdf
“Dlt” is the delta, between that column-of-stats and the first column-of-stats, as a percentage, with {-|+|x}.
For freeware & Oracle, due to not having a Server Architecture, and instead deploying hundreds or thousands of programs running on Unix, the first avenue of “performance monitoring” and even “problem diagnosis”, is via Unix monitoring:
-- top
-- vmstat
“Engine” is a single Unix Process. The Sybase ASE server comprises a grand total of FOUR Engines in this instance, and serves hundreds of active connections (doctors; nurses; medical images; client histories; etc). In contrast, freeware and Oraclewould have hundreds of Unix Processes and no concept of Engine.
Nicola
On Tuesday, 15 June 2021 at 03:39:09 UTC+10, Nicola wrote:The State that is relevant is the State of the whole tree, either the
whole tree is in the OldKey xor the whole tree is in the NewKey.
If you have implemented *Optimistic Locking*
On Wednesday, 16 June 2021 at 18:57:23 UTC+10, Nicola wrote:
On 2021-06-14, Derek Ignatius Asirvadem wrote:
On Tuesday, 15 June 2021 at 03:39:09 UTC+10, Nicola wrote:The State that is relevant is the State of the whole tree, either the whole tree is in the OldKey xor the whole tree is in the NewKey.
Would you mind letting me understand with an example (I'd like to grasp
the overall idea, which I have not yet; I am not asking you to reveal
the secret recipes of your shop) from this document:
https://www.softwaregems.com.au/Documents/Student_Resolutions_2020/Giannis/RoomMonitor%20DM%20V0_51.pdf
Suppose that, for some reason, one needs to update one HotelChain,
changing the value of HotelChain from ABC to H-ABC. If I understand correctly, you would start by (optimistically) locking the record with HotelChain = ABC.
(optimistically)
What would you do next? Insert the new record with key H-ABC into HotelChain, then insert zero or more records referencing H-ABC into
Hotel, then into HotelNetwork, ... (up to 100 inserts), commit; more
inserts (up to 100), commit, etc.?
How would you delete the old records then? With transactions of up to
100 DELETEs each, starting from the bottom of the hierarchy and
navigating the hierarchy up?
If you have implemented *Optimistic Locking*
It's interesting that you mention optimistic locking (have you ever mentioned in before in this group?),
because my understanding was that
you believe that the only correct way to control concurrency was strict pessimistic locking (strict 2PL). This may have been a misunderstanding
on my part.
Suppose that, for some reason, one needs to update one HotelChain,
changing the value of HotelChain from ABC to H-ABC. If I understand
correctly, you would start by (optimistically) locking the record with
HotelChain = ABC.
Yes.
And leave it locked for the duration, it will be the last deleted.
(optimistically)
Because I know that you guys do not understand Locking, let alone
Optimistic Locking, note this this is not an act within that [generic, theoretical] framework. This is a data-level lock (if you have row
locking, and a row locking command, you do not have ACID *and* you
have broken a cardinal rule of OLTP).
On Thursday, 17 June 2021 at 05:45:09 UTC+10, Nicola wrote:
On 2021-06-16, Derek Ignatius Asirvadem wrote:
Suppose that, for some reason, one needs to update one HotelChain,
changing the value of HotelChain from ABC to H-ABC. If I understand
correctly, you would start by (optimistically) locking the record with
HotelChain = ABC.
Yes.
And leave it locked for the duration, it will be the last deleted.
(optimistically)
Because I know that you guys do not understand Locking, let alone Optimistic Locking, note this this is not an act within that [generic, theoretical] framework. This is a data-level lock (if you have row locking, and a row locking command, you do not have ACID *and* you
have broken a cardinal rule of OLTP).
Let me see whether we are on the same tune. While you are performing the batch transaction we are talking about, another transaction may also
attempt to update the record with HotelChain = ABC (and specifically
update the HotelChain field). Is it correct that this second transaction will be allowed to perform the update, and that first (batch
transaction) will detect at the next commit that the "top" row has been overwritten, and rollback (at least rollback the running ACID
transaction)?
Because that is my understanding of "optimistic". But the rest of your
post, (and the remark above) make me doubt that we agree on this
meaning.
1. Lock top-most <Table>[ <OldKey> ]
You need some column that indicates a data-level lock. Standard columns include CreatedDtm; UpdatedDtm; etc, that can be used for this purpose [eg. set CreatedDtm to TODAY+1 or other fixed value [it is temporal, yes] ). You may have IsDeleted to
another transaction may also attempt to
(a) update the record with HotelChain = ABC
(b) (and specifically update the HotelChain field)
On Thursday, 17 June 2021 at 08:36:12 UTC+10, Derek Ignatius Asirvadem wrote:
In this case, that means:
-- UPDATE HotelChain.IsDeleted[ ABC ] = 1
---- WHERE HotelChain.IsDeleted[ ABC ] = 0
or
-- UPDATE HotelChain.IsLocked[ ABC ] = 1
---- WHERE HotelChain.IsLocked[ ABC ] = 0
...
It also prevents:
-- UPDATE Hotel.NumStar[]
or
-- UPDATE HotelRoomType.Description[]
Yes, you do *not* have a correct understanding of Optimistic Locking, none of the academics do, they have only the Stonebraker MVCC Kool Aid, and they have been drinking it and circle-jerking while chanting the *Mantra* for decades. As I have tried toexplain, Optimistic Locking is completely different to the Straw Man that academics erect as “optimistic locking”. This point (your question) has nothing to do with Optimistic Locking.
It has to do with how to construct a Batch Transaction (MonthEnd Procedure at a bank or Move OldKey to NewKey).But of course, we can’t help touching OLTP structures, because it is an OLTP environment, and that is the over-arching requirement.
On Thursday, 17 June 2021 at 08:36:12 UTC+10, Derek Ignatius Asirvadem wrote:
In this case, that means:
-- UPDATE HotelChain.IsDeleted[ ABC ] = 1
---- WHERE HotelChain.IsDeleted[ ABC ] = 0
or
-- UPDATE HotelChain.IsLocked[ ABC ] = 1
---- WHERE HotelChain.IsLocked[ ABC ] = 0
...
It also prevents:
-- UPDATE Hotel.NumStar[]
or
-- UPDATE HotelRoomType.Description[]
Yes, you do *not* have a correct understanding of Optimistic Locking, none of the academics do, they have only the Stonebraker MVCC Kool Aid, and they have been drinking it and circle-jerking while chanting the *Mantra* for decades. As I have tried toexplain, Optimistic Locking is completely different to the Straw Man that academics erect as “optimistic locking”. This point (your question) has nothing to do with Optimistic Locking.
It has to do with how to construct a Batch Transaction (MonthEnd Procedure at a bank or Move OldKey to NewKey).But of course, we can’t help touching OLTP structures, because it is an OLTP environment, and that is the over-arching requirement.
No, that is not correct.
You need some column that indicates a data-level lock. Standard
columns include CreatedDtm; UpdatedDtm; etc, that can be used for this purpose [eg. set CreatedDtm to TODAY+1 or other fixed value [it is
temporal, yes] ). You may have IsDeleted to support SoftDeletes.
Let’s use the easy one, and say you have Soft Deletes. For clarity,
you need a condition [ IsLocked ], and you implement that as indicated
in one of the above columns, if not, you have a column [ IsLocked ].
The fact that there is such a column, and that contention is
understood and consciously minimised, *is* part of Optimistic Locking,
part of the OLTP Standard.
But this is not an ACID Transaction, it is a Batch Transaction. Of
course, we use the column that is there for OLTP purposes, for the now
Batch purpose.
In this case, that means:
-- UPDATE HotelChain.IsDeleted[ ABC ] = 1
---- WHERE HotelChain.IsDeleted[ ABC ] = 0
or
-- UPDATE HotelChain.IsLocked[ ABC ] = 1
---- WHERE HotelChain.IsLocked[ ABC ] = 0
That prevents both [a] and [b] in this:
another transaction may also attempt to
(a) update the record with HotelChain = ABC
(b) (and specifically update the HotelChain field)
It also prevents any Transaction containing:
-- UPDATE Hotel.NumStar[ ABC ]
or
-- UPDATE HotelRoomType.Description[ ABC ]
or
-- INSERT <AnyTableInHierarchy>[ ABC ]
or
-- DELETE <AnyTableInHierarchy>[ ABC ]
Separate point. That “another transaction” sounds suspiciously like another instance of the same transaction, using the same key. That
doesn’t happen in the real world because the person who administers
the first instance of changing ABC is one and the same person who
administers the second instance of changing ABC. This sort of
insanity is /also/ prevented by proper GUI design (a Tree with no
circular references).
On Thursday, 17 June 2021 at 19:27:16 UTC+10, Nicola wrote:
On 2021-06-16, Derek Ignatius Asirvadem wrote:As expected.
No, that is not correct.
You need some column that indicates a data-level lock. Standard
columns include CreatedDtm; UpdatedDtm; etc, that can be used for this purpose [eg. set CreatedDtm to TODAY+1 or other fixed value [it is temporal, yes] ). You may have IsDeleted to support SoftDeletes.
Let’s use the easy one, and say you have Soft Deletes. For clarity,
you need a condition [ IsLocked ], and you implement that as indicated
in one of the above columns, if not, you have a column [ IsLocked ].
The fact that there is such a column, and that contention isThat starts to sound vaguely familiar.
understood and consciously minimised, *is* part of Optimistic Locking, part of the OLTP Standard.
But this is not an ACID Transaction, it is a Batch Transaction. Of
course, we use the column that is there for OLTP purposes, for the now Batch purpose.
In this case, that means:
-- UPDATE HotelChain.IsDeleted[ ABC ] = 1
---- WHERE HotelChain.IsDeleted[ ABC ] = 0
or
-- UPDATE HotelChain.IsLocked[ ABC ] = 1
---- WHERE HotelChain.IsLocked[ ABC ] = 0
That prevents both [a] and [b] in this:
another transaction may also attempt to
(a) update the record with HotelChain = ABC
(b) (and specifically update the HotelChain field)
Is it because each transaction checks UpdatedDtm and finds that it is
equal to TODAY+1, hence it immediately aborts?
It also prevents any Transaction containing:
-- UPDATE Hotel.NumStar[ ABC ]
or
-- UPDATE HotelRoomType.Description[ ABC ]
or
-- INSERT <AnyTableInHierarchy>[ ABC ]
or
-- DELETE <AnyTableInHierarchy>[ ABC ]
Such transactions perform the same check, right? And they abort
immediately, I assume, when they find that the top row has been marked
as deleted by the transaction that set UpdatedDtm. Is that correct?
Separate point. That “another transaction” sounds suspiciously like another instance of the same transaction, using the same key. That doesn’t happen in the real world because the person who administers
the first instance of changing ABC is one and the same person who administers the second instance of changing ABC. This sort of
insanity is /also/ prevented by proper GUI design (a Tree with no
circular references).
It may not happen under normal conditions. But I'd be very worried if
"it cannot happen" relies on correct (human or machine) behaviour.
A system should be resilient to improper and malicious behaviour as
well.
The /Today+1/ is for temporal tables, wherein a current SELECT does
WHERE UpdatedDtm = MAX( UpdatedDtm) less-than-or-equal to today. It
is just the standard method or construct to grab only the current row (exclude historic rows). (Whereas a temporal SELECT would grab the particular historic row.) I expect everyone who implements a temporal
table [using Codd’s temporal definition, not the massive TwiddleDee
& TwidleDumb monstrosity] to know that.
The /Today+1/ just makes the affected row (and the hierarchy below
it) invisible to other users, a form of ISOLATION. Heck, we are on
a planet named ACID, we are performing an [I]solation. Don’t let that confuse you. If the column is there, use it.
If IsDeleted is there, use it.
Else implement IsLocked, and use it.
Since God carved onto the OLTP stone tablet:
__ THOU SHALT NOT ATTEMPT ANYTHING THAT IS IMPOSSIBLE
yes, every Transaction (both ACID and this one) validates everything
it will attempt, before attempting it, before the BEGIN TRAN. In our
case, HotelChain is first. Because it is caught in the VALIDATE
block, before the BEGIN TRAN, there is no “abort” or ROLLBACK TRAN.
The corollary to that Commandment is of course:
__ Thous Shalt Not Begin Anything That Will Fail, That Thou Canst Not Complete.
What you guys call “2 phase” is anti-ACID, it starts a transaction and then fiddles and farts while rambling, meaning time spans between
requests. As per the wiki cesspool article, in the “SS2PL” that we
have, there is only one “phase”.
But we don’t start that “phase” until the previous “phase” of VALIDATE
completes successfully. And we have no time spans in-between
operations.
On Saturday, 19 June 2021 at 00:22:26 UTC+10, Nicola wrote:
On 2021-06-17, Derek Ignatius Asirvadem wrote:
The /Today+1/ is for temporal tables, wherein a current SELECT does
WHERE UpdatedDtm = MAX( UpdatedDtm) less-than-or-equal to today. It
is just the standard method or construct to grab only the current row (exclude historic rows). (Whereas a temporal SELECT would grab the particular historic row.) I expect everyone who implements a temporal table [using Codd’s temporal definition, not the massive TwiddleDee
& TwidleDumb monstrosity] to know that.
The /Today+1/ just makes the affected row (and the hierarchy below
it) invisible to other users, a form of ISOLATION. Heck, we are on
a planet named ACID, we are performing an [I]solation. Don’t let that confuse you. If the column is there, use it.
If IsDeleted is there, use it.
Else implement IsLocked, and use it.
Since God carved onto the OLTP stone tablet:
__ THOU SHALT NOT ATTEMPT ANYTHING THAT IS IMPOSSIBLE
yes, every Transaction (both ACID and this one) validates everything
it will attempt, before attempting it, before the BEGIN TRAN. In our
case, HotelChain is first. Because it is caught in the VALIDATE
block, before the BEGIN TRAN, there is no “abort” or ROLLBACK TRAN.
Wait, what is a VALIDATE block? If an atomic processing unit is
delimited by BEGIN TRAN...COMMIT, how can something before BEGIN TRAN be considered part of that unit? If it is not, then how do you ensure that nothing happens between the instant VALIDATE completes and the instant
BEGIN TRAN is executed?
We know we are locking rows, implicitly, by virtue of the SQL commands we issue, but it is the server that does the locking and the resolution.
how do you ensure that
nothing happens between the instant VALIDATE completes and the instant
BEGIN TRAN is executed?
If an atomic processing unit is
delimited by BEGIN TRAN...COMMIT,
And I have a couple more questions, if you don't mind:
1. What you are describing is built on top of the standard locking
mechanism provided by the DBMS.
If I understand correctly, it requires
the transactions to be coded to perform explicit checks before accessing
the data.
At the outset, that sounds like something that can become very
complicated and error-prone.
Except in high-end servers, where you can write query plans or modify the QPs that the compiler produced. The need for this is essentially to work-around problems caused by bad file design. Since I have only Relational tables, I have never had to use
Now for SG customers, there is much more. I give the OLTP Standard; a set of Templates; and a check list which must be filled by a peer, not the coder, for each xact_sp, before submission to the DBA (to place it in TEST Rdb). The DBA is the policeman,
E.g., it seems that a transaction to insert
a new ReadingMeasure should check many things (HotelChain, CountryCode,
..., Application) before proceeding.
Now for SG customers, there is more. We generate the Transaction sprocs from the SQL Catalogue tables ... with a number of enhancements that I can’t divulge. (Just so that you know such is possible ... it is the next step for IDEs.) So the
Or, wait, such a transaction would be coded in a "simple" way (insert
into Reading, insert into ReadingMeasure)
and then two things may
happen: it is either executed before the batch transaction has "reached" Reading, in which case it would succeed (and then it would be updated by
the batch transaction);
or it is executed after the batch transaction
has updated Reading, hence inserting the new reading would raise
a foreign key violation (and it should be retried with the new key).
Or something else?
2. You are describing an OLTP context, but you have claimed several
times that the same database can serve both OLTP and OLAP workloads.
Do
you code analytic queries along the same principles to avoid
locking too many records?
code analytic queries
I have a simpler form of the Logic Map in IDEF1R, which users prefer over the IDEF1X/Attribute level. That form is the proper replacement for self-crippling *ERD”, that is programmed into young minds at all “universities” as “relational”.
along the same principles to avoid
locking too many records?
OLAP ReportsWhy do you worry about locks in OLAP reports ?
The corollary to that Commandment is of course:
__ Thous Shalt Not Begin Anything That Will Fail, That Thou Canst Not Complete.
That is worth the "optimistic" label!
But we don’t start that “phase” until the previous “phase” of VALIDATE
completes successfully. And we have no time spans in-between
operations.
See above. Not clear how you'd achieve that.
On Saturday, 19 June 2021 at 17:20:51 UTC+10, Derek Ignatius Asirvadem wrote:
Read locks
On Saturday, 19 June 2021 at 17:52:18 UTC+10, Derek Ignatius Asirvadem wrote:
On Saturday, 19 June 2021 at 17:20:51 UTC+10, Derek Ignatius Asirvadem wrote:
Read locks
__ Read locks outside a Transaction are transient, held for the duration of the read operation
__________________
1. VALIDATE Block
Code:
• Read all rows that must exist, in order for the intended rows (INSERT/UPDATE/DELETE) to succeed.
__• RETURN on any failure.
• Check NOT_EXISTS all rows that must not exist, in order for the intended rows (INSERT/UPDATE/DELETE) to succeed.
__• RETURN on any failure.
• Transaction NOT yet started
• All locking is transient and very short duration
• TransactionLog is not touched
• Fall into ...
__________________
2. EXECUTE Block
* BEGIN TRAN
• TransactionLog activity commenced for this xact
• Read all rows that must exist, in order for the intended rows (INSERT/UPDATE/DELETE) to succeed.
__• ROLLBACK & RETURN on any failure.
__• the only relevant locking starts here
__• if blocked by another xact, you are blocked here (NOT after the first verb below)
__• the longest wait is for the longest xact in the system that touches the page
So here we code each SELECT as:
__ IF EXISTS (
____ SELECT ...
______ FROM Hotel
______ WHERE ...
______ { FOR UPDATE | HOLDLOCK } -- platform-specific syntax, “beyond” SQL
____ )
__• <-[2.1]
• Check NOT_EXISTS all rows that must not exist, in order for the
intended rows (INSERT/UPDATE/DELETE) to succeed.
__• ROLLBACK & RETURN on any failure.
• (INSERT/UPDATE/DELETE)
__• ROLLBACK & RETURN on any failure.
• COMMIT TRAN
• TransactionLog is released.
___________________
3. CLEAN-UP Block
• All error handling
• ROLLBACK TRAN (if structured, the only ROLLBACK)
• <-[3.1]
• RETURN (if structured, the only RETURN)
______
Client
There is ordinary interplay between the Client and the Server. The
client may now be a GUI or a webpage or middleware in an app server.
The VALIDATE block [1] is repeated in the client.
how do you ensure that
nothing happens between the instant VALIDATE completes and the instant
BEGIN TRAN is executed?
That duration between instants is:
a. not relevant [assuming you understand the above], and
b. microseconds, because it is between two consecutive steps inside
a contiguous stored proc, which is running as object + plan code
(compiled and a full resource plan established), and
* BEGIN TRAN
• TransactionLog activity commenced for this xact
• Read all rows that must exist, in order for the intended rows (INSERT/UPDATE/DELETE) to succeed.
__• ROLLBACK & RETURN on any failure.
c. harmless because no resources are held.
Batch Transaction
Add:
2.1 Add the data-level lock
___ BEGIN TRAN
___ UPDATE HotelChainIsDeleted[ @HotelChain ] = 1
___ COMMIT TRAN
3.1 Remove the data-level lock (in our example this ois not required, because it is the last row deleted).
___ BEGIN TRAN
___ UPDATE HotelChainIsDeleted[ @HotelChain ] = 0
___ COMMIT TRAN
You may consider the BEGIN-COMMIT TRAN superfluous. No, They are
demanded by the standard. Further, they are anchors for code
investigation, and on the server vis-a-vis monitoring metrics.
1. What you are describing is built on top of the standard locking
mechanism provided by the DBMS.
If you mean the normal ACID Transaction in the full OLTP Context, no.
It is aware of, and implicitly uses the locking in the server
(whatever that is).
If you mean the Batch Transaction, yes. I said so at the start. That
is why I call it a data-level lock, it has to be done in data, we have
no direct access to the locks, and we never do idiotic things such as:
__ LOCK TABLE
OLAP ReportsWhy do you worry about locks in OLAP reports ?
Who cares.
Read locks are extremely short, and transient (held for the duration
of the read operation, not the Transaction). We can’t control Read
locks, even implicitly
But still, that is not Optimistic Locking. And in this post, there is nothing about Optimistic Locking.
On Saturday, 26 June 2021 at 20:56:40 UTC+10, Nicola wrote:
On 2021-06-26, Derek Ignatius Asirvadem wrote:
Trivially, as MVCC does not use locks.
Are you agreeing that MV-non-CC cannot support SQL/ACID ? Finally, hallelujah !!!
I am not sure that by ACID compliance we mean the same thing. You seem
to imply more than what the acronym stands for (or I am taking a narrow interpretation of it). But I am not excluding that you may be right. Hopefully, we will be able to clarify this.
On Sunday, 27 June 2021 at 19:11:07 UTC+10, Derek Ignatius Asirvadem wrote:not integration, not atoms. And that means (b) bottom-up, instead of top-down. So you have noticed and copied things correctly, but the overall need, and the integration within the Atom, is not complete.
The thing is this. And both Nicola and you have this problem. Not because you are stupid, you are not, but due to the programming that passes for “education” that has been imposed on you. You have been trained to (a) think in terms of fragments,
On Saturday, 26 June 2021 at 22:34:46 UTC+10, Nicola wrote:
On 2021-06-26, Daniel Loth wrote:
Thirdly is the meticulous transaction control. All transactions live within the database, implemented as procedures.
Again, I agree with Derek on this. Of course, we are talking about *database* transactions, not *business* transactions (e.g., buying an
item on an online shop is one business transaction, but it is carried
out through several database transactions).
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 91:40:51 |
Calls: | 6,658 |
Files: | 12,203 |
Messages: | 5,334,171 |