There's one thing that you have to know when working with this feature. If you restart the server the "reserved" block gets lost for ever. So when you start with a fresh form, and have reserved 1000 entry id's, the first entry id will be 000...1. If you restart the server 999 entry id's ar e "lost" so the new next entry id (the second ticket in the form) would be entry id 000001000 and not 00000..2.
Hugo On 2/8/07, Hall Chad - chahal <[EMAIL PROTECTED]> wrote:
I'm really looking forward to this feature. We've had a lot of slow response issues that we've traced back to 10 or more SQL Server processes waiting for a lock on the arschema table to free up. In some instances it might take a full minute for one of them to finally complete. Oddly SQL Server's sysprocesses table shows zero 'waittime' on all of those processes. That part I simply can't understand. We have 20 Fast, 20 List, with private threads for email, DSO, reports, etc. We generate 60,000 emails per day, 50,000 DSO transactions per day, 3,000 tickets per day, 50,000 records per day on a tracking form, etc. I'm surprised we don't see this problem more often than we do. Can't wait to upgrade to 7.x! Chad Hall (501) 342-2650 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] On Behalf Of Ben Chernys Sent: Thursday, February 08, 2007 8:18 AM To: arslist@ARSLIST.ORG Subject: Re: Next-ID-Block-Size Server threads. Though if your client is single-threaded, the server will only allocate one thread to that client session. So yes, both would have to be multi-threaded. You can emulate this by spawning multiple instances of a single threaded client against a multi-threaded server. Again, though the improvements comes when you are creating multiple records on different tables through workflow in an out-of-sequence manor simultaenously across multiple threads. Rick is correct in that when block IDs are used the locking on the arschema goes away. In fact, a single, separate, private server thread is used for next ids when next id blocking is enabled. So, really, the feature is very useful for preventing a "deadlock" issue on arschema which is possible with the example I have given below. Cheers Ben >----- ------- Original Message ------- ----- >From: Rick Cook <[EMAIL PROTECTED]> >To: arslist@ARSLIST.ORG >Sent: Thu, 8 Feb 2007 06:53:20 > >As I recall, it allows mechanisms that use a large >number of Request IDs in >a short time (like an NMS) to only go to the DB >once to grab the defined >chunk of IDs and cache them for its own use, rather >than constantly go ask >for them one at a time. > >Rick > >On 2/8/07, Jarl Grøneng <[EMAIL PROTECTED]> >wrote: >> >> Thanks, >> >> Do you mean several threads on the server, or >several treads from the >> client? I has a import program doing this, but >will rewrite it to >> support multiple threads. >> >> -- >> Jarl >> >> On 2/8/07, Ben Chernys ><[EMAIL PROTECTED]> wrote: >> > This only has effect if you are running >multiple threads. Further, the >> real use is to not place a lock on arschema so >the effects will not be >> noticed until you have workflow creating multiple >records firing >> simultaenously across multiple threads (possibly >in different orders and >> timings). >> > >> > Example: >> > Thread 1 Thread 2 >> > cre XXX cre YYY >> > wait 1s cre XXX >> > cre YYY wait 1s >> > cre XXX cre XXX >> > >> > Cheers >> > Ben >> > >> > >----- ------- Original Message ------- ----- >> > >From: =?ISO-8859-1?Q?Jarl_Gr=F8neng?= >> > ><[EMAIL PROTECTED]> >> > >To: arslist@ARSLIST.ORG >> > >Sent: Thu, 8 Feb 2007 12:33:03 >> > > >> > >Hi, >> > > >> > > >> > >Has anyone notice any incrase in performance >> > >setting >> > >Next-ID-Block-Size to a value higher than 2? >> > > >> > >Tried setting this up to 1000, but does not >notice >> > >any increase in >> > >create operation. >> > > >> > >-- >> > >Jarl >> > > >> > >>__________________________________________________ >_ >> > >____________________________ >> > >UNSUBSCRIBE or access ARSlist Archives at >> > >www.arslist.org ARSlist:"Where the Answers >Are" >> > >> > >> >___________________________________________________ >____________________________ >> > UNSUBSCRIBE or access ARSlist Archives at >www.arslist.org ARSlist:"Where >> the Answers Are" >> > >> >> >> >___________________________________________________ >____________________________ >> UNSUBSCRIBE or access ARSlist Archives at >www.arslist.org ARSlist:"Where >> the Answers Are" >> > > > >-- >Rick Cook >Cook Enterprises >253-278-4112 > >___________________________________________________ >____________________________ >UNSUBSCRIBE or access ARSlist Archives at >www.arslist.org ARSlist:"Where the Answers Are" >** ><div>As I recall, it allows mechanisms that use a >large number of Request IDs in a short time (like >an NMS) to only go to the DB once to grab the >defined chunk of IDs and cache them for its own >use, rather than constantly go ask for them one at >a time. ></div> ><div></div> ><div>Rick<br></div> ><div><span class="gmail_quote">On 2/8/07, <b >class="gmail_sendername">Jarl Grøneng</b> <<a >href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] >mail.com</a>> wrote:</span> ><blockquote class="gmail_quote" >style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px >0.8ex; BORDER-LEFT: #ccc 1px >solid">Thanks,<br><br>Do you mean several threads >on the server, or several treads from >the<br>client? I has a import program doing this, >but will rewrite it to ><br>support multiple >threads.<br><br>--<br>Jarl<br><br>On 2/8/07, Ben >Chernys <<a >href="mailto:[EMAIL PROTECTED]">ben >[EMAIL PROTECTED]</a>> >wrote:<br>> This only has effect if you are >running multiple threads.Further, the >real use is to not place a lock on arschema so the >effects will not be noticed until you have workflow >creating multiple records firing simultaenously >across multiple threads (possibly in different >orders and timings). ><br>><br>> Example:<br>> >Thread >1&n >bsp; >Thread 2<br>> cre >XXX >&nb >sp;cre YYY<br>> >wait >1s& >nbsp;&nbs >p;cre XXX<br>> cre >YYY >&nb >sp;wait 1s<br>> >cre >XXX >&nb >sp;cre XXX ><br>><br>> Cheers<br>> Ben<br>><br>> >>----- ------- Original Message ------- >-----<br>> >>From: > =?ISO-8859-1?Q?Jarl_Gr=F8neng?=<br>> >><<a >href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] >MAIL.COM ></a>><br>> >>To:&n >bsp; <a >href="mailto:arslist@ARSLIST.ORG";>[EMAIL PROTECTED] >RG</a><br>> >Sent: Thu, 8 Feb 2007 >12:33:03<br>> ><br>> >Hi,<br>> >><br>> ><br>> >Has anyone notice any >incrase in performance ><br>> >setting<br>> >Next-ID-Block-Size >to a value higher than 2?<br>> ><br>> >>Tried setting this up to 1000, but does not >notice<br>> >any increase in<br>> >>create operation.<br>> > ><br>> >--<br>> >Jarl<br>> >><br>> >>_______________________________________________ >____<br>> >>____________________________<br>> >>UNSUBSCRIBE or access ARSlist Archives >at<br>> ><a href="http://www.arslist.org";> >www.arslist.org</a> ARSlist:"Where the Answers >Are"<br>><br>> >___________________________________________________ >____________________________<br>> UNSUBSCRIBE or >access ARSlist Archives at <a >href="http://www.arslist.org";> >www.arslist.org</a> ARSlist:"Where the Answers >Are"<br>><br><br>__________________________ >___________________________________________________ >__<br>UNSUBSCRIBE or access ARSlist Archives at <a >href="http://www.arslist.org";> >www.arslist.org</a> ARSlist:"Where the Answers >Are"<br></blockquote></div><br><br >clear="all"><br>-- <br>Rick Cook<br>Cook >Enterprises<br>253-278-4112 >__20060125_______________________This posting was >submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" *************************************************************************** The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank You. **************************************************************************** _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
