Re: User Space question

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:

Chuck,

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...

D*B
--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.