Re: Oracle NEXTVAL Best Practice

Steven Burrows

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 !?!


Steven Burrows



From: [] 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@...>:

Addendum to this,

The aforementioned batch task is being called from within another batch task's Group Prefix logic unit, and in which Transaction mode is Physical, Begin at a Group level. I subsequently have changed the above batch task to Physical-None, still no luck.

I'm thinking about making the above batch task a parallel task, so it would be called from outside the active transaction, but clearly I'm just throwing shit against the wall now to see if anything sticks.


Steve Blank

Join { to automatically receive all group messages.