Hi, I actually tried removing the two lines from ar.cfg with Next-ID-Commit and Next-ID-Block-Size. The default is "T" and 25 in 7.6.04 (unpatched).
Here is the log: http://rrr.se/tmp/rrrLog764nextId.html I had to set Next-ID-Commit it to "F" to have the old functionality when the arschema-table is NOT updated if a transaction is rolled back. One more question regarding locking. Do you really lock the WHOLE arschema-table, not only the row in question? 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. > 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:[email protected]] On Behalf Of Misi Mladoniczky > Sent: 12 October 2011 10:16 > To: [email protected] > 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:[email protected]] On Behalf Of Misi Mladoniczky >> Sent: 12 October 2011 08:29 >> To: [email protected] >> 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:[email protected]] On Behalf Of Misi Mladoniczky >>> Sent: 12 October 2011 07:30 >>> To: [email protected] >>> 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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
