There is no doubt that the i database is very efficient. But, and I'm
assuming efficiency is being measured in terms of code path executed, a
simple CMPSWP operation on a shared *USRSPC location (I'm assuming some
locking protocol is in place for concurrent increments) is at a minimum
100s (and I strongly suspect 1000s if you throw in journaling and commit
control) of times shorter in terms of instructions executed when compared
to a database operation.

Bruce Vining

On Sat, Dec 6, 2014 at 1:16 PM, D*B <dieter.bender@xxxxxxxxxxxx> wrote:


mostly I'm with you, but in this case???
There is nothing more efficcient, than a database table, it's designed for
millions of updates and from the programmers perspective the one table for
all solutions beats them all. If you don't have a record for a new table,
the getKey function just inserts it. We've used this for a massive parallel
load process for a data warehouse and implemented a blocking mechanism
(draw x keys for one) and it outperformed even the autoincrement keys of
teh database. You've have to be precise with the locking of this table
(best was: use commit repeatable read and start with the update and read
afterwards), but once have it right and you will never have a look to it...
I'm using (at the moment, maybe it will bereplaced with sockets further on)
DataQs frequently with ArdGate, but for synchronous work, with need of
persitence, there are better solutions...

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].