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 <axton.gr...@gmail.com> 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 > > On Wed, Oct 12, 2011 at 10:17 AM, Rick Cook <remedyr...@gmail.com> wrote: > >> ** Well of course there is the potential for contention, the question is >> whether that contention causes any kind of noticeable latency and whether >> the solution is better than the problem. Within that context, does the >> scenario I laid out below have a logical flaw? >> >> >> Rick >> >> On Wed, Oct 12, 2011 at 8:08 AM, Axton <axton.gr...@gmail.com> wrote: >> >>> ** If you have more than 1 thread, you have a potential for resource >>> contention. On seperate threads you can create an entry in the same form. >>> If each transaction has to update/commit the same record in arschema, you >>> can get a bottleneck. By managing the numbers in memory (versus the db), >>> you can fetch and use a block of IDs, thus alleviating the contention on the >>> record in arschema. >>> >>> Axton Grams >>> >>> On Wed, Oct 12, 2011 at 9:20 AM, Rick Cook <remedyr...@gmail.com> wrote: >>> >>>> ** Mark, isn't that bottleneck only an issue when multiple sources (such >>>> as NMS) are attempting to submit multiple entries to the same form at the >>>> same time? That was the initial problem that the Next-ID block was added >>>> to >>>> alleviate. If so, I fail to see the value-add to making a larger value >>>> than >>>> "1" a global setting. And if a company has a low volume of records without >>>> the streaming issue above, what is the value add at all? >>>> >>>> >>>> This seems like a global answer for a problem very few companies are >>>> having. >>>> >>>> Rick >>>> >>>> >>>> On Wed, Oct 12, 2011 at 3:32 AM, Walters, Mark <mark_walt...@bmc.com>wrote: >>>> >>>>> Before the block size option was introduced there was a potential >>>>> bottleneck on the arschema table when a large number of records were being >>>>> created as each new record needed to update the nextId for the form in >>>>> this >>>>> table. The default behavior was to update the nextID to get the new >>>>> request >>>>> id but not to commit this change until the new record creation completed. >>>>> If there was a lot of workflow run during the submit this could cause a >>>>> performance problem as threads would be unable to get at the arschema >>>>> table >>>>> until the thread that was using it completed its transaction. >>>>> >>>>> When the Next-ID-Commit setting was enabled this caused the server to >>>>> issue a commit as soon as it had updated the nextID, thereby releasing the >>>>> arschema table for other threads to use. >>>>> >>>>> Now that we have next id blocks the arschema table is only updated when >>>>> the block is refreshed so there original setting is redundant in this >>>>> case. >>>>> >>>>> The default for Next-ID-Commit is FALSE in 7.6.04. >>>>> >>>>> From the 7.6.04 config guide; >>>>> >>>>> Next-ID-Commit: >>>>> >>>>> Flag indicating whether to perform a new commit transaction when the >>>>> system generates the next ID for a record in the database. Values are >>>>> T—Perform a new commit transaction. To increase efficiency and >>>>> for debugging, use this value. >>>>> F—(Default) Include the transaction to generate the next ID in >>>>> the create entry transaction. >>>>> >>>>> This option does not work with Informix databases. >>>>> >>>>> Note: Next-ID-Block-Size replaced Next-ID-Commit, but Next-ID-Commit is >>>>> available for backward compatibility >>>>> Next-ID-Block-Size Option that allocates next IDs in blocks instead of >>>>> one at a time. >>>>> >>>>> From a quick test setting the block size to 1 for a form and then >>>>> setting Next-ID-Commit to T works as you would expect and commits the >>>>> update >>>>> to arschema after incrementing the nextId. >>>>> >>>>> mark >>>>> >>>>> -----Original Message----- >>>>> From: Action Request System discussion list(ARSList) [mailto: >>>>> arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >>>>> Sent: 12 October 2011 10:16 >>>>> To: arslist@ARSLIST.ORG >>>>> Subject: Re: Next Request ID Block Size - Info required >>>>> >>>>> Hi, >>>>> >>>>> If I understand you correct, if you have the Next-ID-Block-Size set to >>>>> a value greater than 1, the Next-ID-Commit has no relevance. >>>>> >>>>> Why make a Next-ID-Commit default of "T" and Next-ID-Block-Size of "25" >>>>> the default in that case? >>>>> >>>>> If I want a unbroken serial on one form, I guess I can do something >>>>> like this without impacting performance on anything else: >>>>> Next-ID-Block-Size:25 >>>>> Next-ID-Commit:F >>>>> Form-Specific-Next-ID-Block-Size:1 (form property via DevStudio) >>>>> >>>>> This would give me what I want, and the 25 would make any other form >>>>> work with the same performance benefits as the 7.6.04 default setting. >>>>> Right? >>>>> >>>>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP >>>>> 2011) >>>>> >>>>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): >>>>> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >>>>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy >>>>> logs. >>>>> Find these products, and many free tools and utilities, at >>>>> http://rrr.se. >>>>> >>>>> > Sorry, nothing on that one. >>>>> > >>>>> > I must admit I've never really understood the requirement to have >>>>> > linear request ids. That's not to say there's not a good reason you >>>>> > might want to do this but I don't see the need. There has never been >>>>> > a guarantee that there would be no gaps in the sequence - a failed >>>>> > submit may leave a gap for example - and this has always been the >>>>> case. >>>>> > >>>>> > The Next-ID-Commit was introduced as a performance tweak to reduce >>>>> > contention on the arschema table when the nextId was being >>>>> incremented. >>>>> > If you're using next id blocks it is redundant as the call to >>>>> > increment the nextId is only made when the server has used all the >>>>> ids >>>>> > in the block and needs to get the next chunk, not on every record >>>>> submit. >>>>> > >>>>> > Mark >>>>> > >>>>> > -----Original Message----- >>>>> > From: Action Request System discussion list(ARSList) >>>>> > [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >>>>> > Sent: 12 October 2011 08:29 >>>>> > To: arslist@ARSLIST.ORG >>>>> > Subject: Re: Next Request ID Block Size - Info required >>>>> > >>>>> > Hi, >>>>> > >>>>> > You learn something new every day, right :-) >>>>> > >>>>> > What about the Next-ID-Commit on a per-form-basis? That would be >>>>> > equally important if you want your IDs in a straight line. >>>>> > >>>>> > Best Regards - Misi, RRR AB, http://rrr.se >>>>> > >>>>> >> Next-ID-Block-Size can be set per form - it's an option that can be >>>>> >> enabled under Form, Properties. >>>>> >> >>>>> >> Mark >>>>> >> >>>>> >> -----Original Message----- >>>>> >> From: Action Request System discussion list(ARSList) >>>>> >> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >>>>> >> Sent: 12 October 2011 07:30 >>>>> >> To: arslist@ARSLIST.ORG >>>>> >> Subject: Re: Next Request ID Block Size - Info required >>>>> >> >>>>> >> Hi, >>>>> >> >>>>> >> What happens is that each thread will reserve 10 numbers at a time. >>>>> >> >>>>> >> This means that thread "1" will create something like number 15-24, >>>>> >> and that the next thread will get 25-34 etc. >>>>> >> >>>>> >> This also means that the creation time of record 25 may be prior to >>>>> >> lets say 18. >>>>> >> >>>>> >> In pre 7.6.04, the default value was 1, but it is now 25, which is a >>>>> >> big change. >>>>> >> >>>>> >> Another important thing is the Next-ID-Commit setting, that will >>>>> make >>>>> >> sure that a number is not used until the record hits the database. >>>>> >> >>>>> >> New default settings from ar.cfg/conf in 7.6.04: >>>>> >> Next-ID-Commit:T >>>>> >> Next-ID-Block-Size:25 >>>>> >> >>>>> >> Default values från earlier version: >>>>> >> Next-ID-Commit:F >>>>> >> Next-ID-Block-Size:1 >>>>> >> >>>>> >> It would be very nice if you could set this on a per form basis. I >>>>> >> know many instances where you want to keep your request ids both >>>>> >> straight and strict... >>>>> >> >>>>> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP >>>>> >> 2011) >>>>> >> >>>>> >> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): >>>>> >> * RRR|License - Not enough Remedy licenses? Save money by >>>>> optimizing. >>>>> >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy >>>>> >> logs. >>>>> >> Find these products, and many free tools and utilities, at >>>>> >> http://rrr.se. >>>>> >> >>>>> >>> Hi All, >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> I need your help to understand the form property "Next Request ID >>>>> >>> Block Size". What I understood if I enable this property and set it >>>>> >>> to as say 10. I would get request id as 2,12, 22,32 on the >>>>> >>> subsequent created request on that form. But it did not happen that >>>>> way. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Could any expert please throw a little light on this form property >>>>> >>> and use of it. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> PS: We also have similar setting on Server Information form, I >>>>> guess >>>>> >>> that is for setting globally for all forms and can be overwritten >>>>> >>> for a particular form using form property. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Please correct me if I am wrong >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Ashutosh >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Think green - keep it on the screen. >>>>> >>> >>>>> >>> This e-mail and any attachment is for authorised use by the >>>>> intended >>>>> >>> recipient(s) only. It may contain proprietary material, >>>>> confidential >>>>> >>> information and/or be subject to legal privilege. It should not be >>>>> >>> copied, disclosed to, retained or used by, any other party. If you >>>>> >>> are not an intended recipient then please promptly delete this >>>>> >>> e-mail and any attachment and all copies and inform the sender. >>>>> Thank you. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> ____________________________________________________________________ >>>>> >>> _ _ _________ UNSUBSCRIBE or access ARSlist Archives at >>>>> >>> www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the >>>>> >>> Answers Are" >>>>> >>> >>>>> >> >>>>> >> >>>>> _____________________________________________________________________ >>>>> >> _ _________ UNSUBSCRIBE or access ARSlist Archives at >>>>> www.arslist.org >>>>> >> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>> >> >>>>> >> >>>>> _____________________________________________________________________ >>>>> >> _ _________ UNSUBSCRIBE or access ARSlist Archives at >>>>> www.arslist.org >>>>> >> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>> >> >>>>> > >>>>> > >>>>> ______________________________________________________________________ >>>>> > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>>>> > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>> > >>>>> > >>>>> ______________________________________________________________________ >>>>> > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>>>> > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>> > >>>>> >>>>> >>>>> _______________________________________________________________________________ >>>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend >>>>> wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>> >>>>> >>>>> _______________________________________________________________________________ >>>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>> >>>> >>>> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ >>>> >>> >>> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ >>> >> >> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ >> > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
