Re: User Space question

[Bruce Vining <bvining@xxxxxxxxxxxxxxx>]

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.