No, next id blocks operate at the server level, not the thread level. Mark
________________________________ From: Action Request System discussion list(ARSList) [arslist@ARSLIST.ORG] On Behalf Of Rick Cook [remedyr...@gmail.com] Sent: 12 October 2011 18:50 To: arslist@ARSLIST.ORG Subject: Re: Next Request ID Block Size - Info required ** Yup. That's correct, and has been expanded upon by Misi to include Threads, Mark. So I think your equation is actually B X S X T = allocated IDs. To what degree a customer might care about that will vary, and most probably won't as long as they know the cause. But why introduce even a minor annoyance like that without a good reason, especially since the usage and scope of the setting seems to be expanding? It seems that BMC knows a good bit more about the function and pros/cons of this setting than is documented for their customers who aren't reading threads like this one. Given that set of circumstances, changing a default setting seems premature, if not misguided. The setting should be given as an option to those few customers who will benefit from it, not foist upon all who must now change it or live with its somewhat quirky consequences. Rick On Wed, Oct 12, 2011 at 10:40 AM, Walters, Mark <mark_walt...@bmc.com<mailto:mark_walt...@bmc.com>> wrote: If you're using next id blocks any unallocated ones are lost when the server restarts. Consider a form with block size set to 10. On the first CreateEntry call to this form the server will read the nextId for the schema from the arschema table and increment it by 10. This transaction is commited to the database regardless of Next-ID-Commit setting. Subsequent CreateEntry calls will use a request id from the block in memory until they are exhausted at which point the arschema value is bumped up another 10. Now, if the server is restarted and only 5 of the 10 ids in memory have been used, the remainder are lost. When the server starts again it will allocate the next 10 ids above the current nextId value in the arschema table for the form. This situation is compounded in a server group where each server would take 10 ids so, at a maximum, you could get a gap of B x S ids where B is the block size and S the number of servers in the group. Mark ________________________________________ From: Action Request System discussion list(ARSList) [arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Misi Mladoniczky [m...@rrr.se<mailto:m...@rrr.se>] Sent: 12 October 2011 16:04 To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Next Request ID Block Size - Info required Hi, Hm... I do not think so... If the database has received the COMMIT, everything should be in the database. If not, the database would roll back, right??? Best Regards - Misi, RRR AB, http://rrr.se > You will also get gaps on a server restart, unless the Next-ID-Commit > covers > that as well. > > For those whose records are subject to oversight, will missing records, or > records whose IDs were not create chronologically, create any audit > issues? > > Rick > > On Wed, Oct 12, 2011 at 7:08 AM, Grooms, Frederick W < > frederick.w.gro...@xo.com<mailto:frederick.w.gro...@xo.com>> wrote: > >> Misi, >> >> I can think of a case where a gap will occur. If I have a form that on >> submit fires a filter that does a push to a 2nd (or 3rd, 4th, ...) form >> and >> that push fails then the 1st form's record will be backed out. With >> multiple users on the system a second user could create a record in the >> 1st >> form during the time that the 1st user is doing the push to the child >> forms >> (especially if the push to child forms is conditional on data submitted >> in >> the 1st form). This would leave a hole in the sequence of ID on the 1st >> form. >> >> Fred >> >> -----Original Message----- >> From: Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Misi >> Mladoniczky >> Sent: Wednesday, October 12, 2011 4:10 AM >> To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> >> Subject: Re: Next Request ID Block Size - Info required >> >> Hi, >> >> A failed submit has never left a gap in the id range until the >> Next-ID-Commit:T was introduced. >> >> I have depended on this since version 2.0 of the AR System. >> >> There are many cases when it is useful, or required, to have an unbroken >> serial number. >> >> You can build your own workflow to try to accomplish this, but it is not >> that easy to make it right, and it involves meddling with the filter >> phasing and database commits... >> >> Historically, the next-id-generation has been a dependable counter! >> >> 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. >> >> > -----Original Message----- >> > 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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Misi >> > Mladoniczky >> > Sent: 12 October 2011 08:29 >> > To: arslist@ARSLIST.ORG<mailto: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<mailto:arslist@ARSLIST.ORG>] On Behalf Of >> >> Misi Mladoniczky >> >> Sent: 12 October 2011 07:30 >> >> To: arslist@ARSLIST.ORG<mailto: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 frn 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. >> >> >> >>> -----Original Message----- >> >>> 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 >> >> >> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at >> www.arslist.org<http://www.arslist.org> >> attend wwrug11 www.wwrug.com<http://www.wwrug.com> ARSList: "Where the >> Answers Are" >> > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at > www.arslist.org<http://www.arslist.org> > attend wwrug11 www.wwrug.com<http://www.wwrug.com> ARSList: "Where the > Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> attend wwrug11 www.wwrug.com<http://www.wwrug.com> ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> attend wwrug11 www.wwrug.com<http://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"
