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 <[email protected]> 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 <[email protected]> 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 <[email protected]>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: >>> [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" >>> >> >> _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"
