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"
