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"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
