Hi,
If you do not meddle with the phases and commits, I think you might be
wrong...
With the following settings, everything should be rolled back.
Next-ID-Commit:F
Next-ID-Block-Size:1
All other simultaneous submits to these forms has to wait until we are
done, either successfully or rolled back.
Best Regards - Misi, RRR AB, http://rrr.se
> 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:[email protected]] On Behalf Of Misi Mladoniczky
> Sent: Wednesday, October 12, 2011 4:10 AM
> To: [email protected]
> 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:[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 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
> 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"
