Thanks, Mark. The count is set per server, then there's a check box on each form to enable it to use that server number.
We'll have to evaluate whether having Entry IDs/Create Dates out of sync is worth the performance increase. I suspect that it will be, but we may still have to check our apps and users to ensure no one gets hosed in the trade-off. Rick On Fri, May 9, 2008 at 11:07 AM, Walters, Mark <[EMAIL PROTECTED]> wrote: > When this setting is enabled the server will increment the nextid count in > the arschema table for the form by the configured number. Once the server > has allocated all the ids the next block is fetched. If the server is > terminated for any reason, intentionally or otherwise, any unused ids will > be discarded and there will be a gap in the request id sequence in the form. > If you're using a server group and each server is using the feature there > is increased potential for these gaps to occur. Each server is independant > in the use of this feature - you could have servers using different values > for the nextid block or a mix of servers with the setting enabled and > disabled. The next id count can also be set per form if I recall correctly > (don't have the docs handy). > > The occurrence of gaps in the request id sequence has always been a > possibility - consider the case of a heavily used form with mutliple users > running submits. If the workflow that creates a new record has conditions > that may cause the submit to be cancelled the transaction would be backed > out and, if subsequent submits had already started, this would result in a > gap. > > Mark > > ________________________________ > > From: Action Request System discussion list(ARSList) on behalf of Rick Cook > Sent: Fri 09/05/2008 17:32 > To: [email protected] > Subject: Next ID Blocks in Server Groups > > > ** We are upgrading to AR System 7.1 (no ITSM - all custom apps), and are > looking at the potential performance gains of using the pre-allocated nextId > blocks. > > I attended the BUW session where they talked about the optimal setting > being about 100 for heavily used forms, but I got to thinking "What would > happen in a fail-over situation? How do the servers play together with > those pre-allocated blocks?" My thought was that at worst, the allocated > but as yet unused portion of the block would be discarded, and a new one > would be spawned on the new primary server, leaving ID gaps of between 1 and > 99. That, we could live with. > > While digging through the 7.1 docs, I read this little gem in the O&T, > which seems to sort of obliquely reinforce my opinion: > > The use of this configuration setting could result in unpredictably large > NextID sequence gaps. The likelihood of this occurring increases with the > use of multiple servers that share a database. The AR System server will not > malfunction due to this gap and should not be considered a defect. > > Has someone been through this exercise who could offer some insight into > whether there might be other issues to be aware of? Is this a setting that > could be different for different servers in a group (not that I know why one > WOULD, but...)? > > Also, I found it a bit disturbing that the documentation said to adjust > this value in the ar.conf file when there is a setting in the Administration > form for it (which the doc does not mention). They probably just didn't > update that from 7.0.1, but it does tend to make one wonder about the > completeness of the rest of the information. > > Rick > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
