Great conversation, and hopefully the bear from the black forest will show up :-) !
The solution to this is probably to steer away from Entry Ids, and rely on GUIDs instead. I think BMC is moving into that direction, when will that happen I don't know. BTW the concept of the "next request ID block size" is very similar from Oracle sequences, maybe BMC got the idea from there. In Oracle, sequences can also have holes if there is some kind of crash or threads die suddenly. Since sequences are kept in memory (for speed of retrieval and update), awhen there is a crash, the sequence will have holes; this is known issue that people and developers deal with. Maybe 11g has aliviated some of these issues, but I have not seen anything that would point to that. I believe SQL Server also has sequences, but I don't know how it's implemented there. So... the concept is definitely useful and has many applications, whether in the Remedy realm or other realms, in applications of all sorts where large amounts of data is processed; since companies and people and systems keep producing more and more data for pretty much anything, it was just a matter of time that Remedy would follow the concept. Guillaume ________________________________ From: Action Request System discussion list(ARSList) [[email protected]] on behalf of Rick Cook [[email protected]] Sent: Wednesday, October 12, 2011 1:02 PM To: [email protected] Subject: Re: Next Request ID Block Size - Info required ** I agree with your technical dissection of the construct, Axton. When I presented my findings to BMC a few years ago, their engineers basically said the same thing. I have no problem with the idea behind it, or its function. It certainly has a real value to a relatively few larger customers who pump thousands or tens of thousands of entries into their Remedy systems daily. But that's where the value ends, IMO. I therefore don't understand why BMC made this setting (value depends on the version) the default across all forms, since it messes up, or presents the potential to mess up, other things. These aren't big things, but they are anomalies in say, the synchronization between Entry ID and Create Date, or the possibility of missing Entry IDs, that are introduced with no corresponding value add. I would like to see BMC explain their decision to apply OOB settings for all customers that really offer value only to a very small percentage of their customers. Rick On Wed, Oct 12, 2011 at 9:50 AM, Axton <[email protected]<mailto:[email protected]>> wrote: ** If one transaction updates arschema.nextid, does it's other processing, then commits, any subsequent update to that row in arschema will be blocked until that commit on the initial transaction completes. This will occur if "Next-ID-Commit:F", which is the default on 7.5. It's not a big issue until you start trying to create a lot of new records on a single form using multiple threads. When you have that condition, setting the above to T (which is non-issue when NextID-Block-Size > 1 is defined) will have a drastic impact on throughput. The higher the concurrency, the larger the impact. Common examples of high concurrency would include many users submitting incidents; distributed clients that all send data to your remedy server at the same or near same time, etc. None of this is a deal breaker until the time to wait exceeds the timeout, at which point things really break. The worst case, up to the point of breaking, is lower throughput. I don't have any numbers to offer; this is all speculation on my part based on my understanding of how these things work. Numbers would be nice, wish I had the time to draw some up. Axton Grams _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
