Re: Oracle NEXTVAL Best Practice
We have a parallel “get next” methodology in our MSSQL system. Works very well, but isn’t lightning fast. Is fine for Online, but for a batch it could really slow the process down. However, as long as the IDs are internal, there is no reason you could not reserve 100 ids in a single call to reduce the number of spawns.
…or try something we learnt the other day in MSSQL, which might apply to other DBs. Do a link write with Transaction NONE, Locking NONE, and Magic creates a new connection (separate one-off transaction). It is still an SQL transaction, and the record is of course locked, cos it cant be any other way, but it is not part of your existing transaction. Who would ever try such a dumb-arse thing !?!
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Frederik Soete
Sent: 16 August 2017 20:21
Subject: Re: [magicu-l] Oracle NEXTVAL Best Practice
Or what if your calling task had physical transaction beginning before record prefix, instead of the none or group change? That value seems like in between the other two options, and was for me a way to avoid a quirk or bug w.r.t. physical/none in XPA 3.2. And the group change thing: i do not know when those updates are committed in a physical transaction, so that could maybe cause interference? Does your first grouping get a good ID, but not the rest?
Op 16 aug. 2017 18:35 schreef "Steven Blank" <sgblank@...>: