CMPSWP isn't IBM i only, it's a pattern used in many places and will have implementations practically everywhere, much of the time in the firmware/hardware of the machine itself. Because of that it's also very, very fast and guaranteed to be atomic. I'd be surprised if there's a faster solution .
As I said before, I wouldn't use it instead of a native DB solution except in cases where you have no choice.
Tim.
Get Outlook for Android<
https://aka.ms/ghei36>
________________________________
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of D*B <dieter.bender@xxxxxxxxxxxx>
Sent: Tuesday, December 15, 2020 9:44:08 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: The age-old database design question - Integers or GUID/UUID for primary keys ? What are your thoughts ?
some additional thoughts inspirated by other posts:
@DTAARA:
a better aproach would be a database based solution: we used one file
(dbname, filename, maxkey) for all needed keys and one function
getKey(dbname, filename, blockSize) returning the starting Number of the
block. Inside the function it's a little bit tricky to avoid collisions and
deadlocks (start with the update of the keyfile, then read the maxKey,
afterwards commit - you need a commitscope of its own -> named ACTGRP, for
other DBs connection of its own). If there is no row for dbname, filename,
simply insert one to start - so you would not need a maintenance function.
This should work for all databases I know - without any risc of key
conflicts during insert.
@autoincrement: There might be diffrences for diffrent databases and even
worse: it might get complex to consolidate data originating from diffrent
databases.
@CMPSWP solution: this is as400 only and it might be a bottleneck for
maximum throughput. In the business warehouse project, I mentioned before,
we used massiv parallelism to speed up the load process to its maximum. To
get more speed, we only needed a higher number of CPUs and a change in our
configuration. So speed was only limited by the maximum number of CPUs.
D*B
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
