Thanks Fred! and yes, that is where our deadlocks happened as well. (ARSCHEMA). I should have mentioned that before, sorry.
Thanks for that tip!!! ************ It doesn’t have to be just Network Management (or other apps) creating large number of records in a form. In our custom system we have a history form (with a type value) to do audit trail work. The Oracle DBA was reporting deadlocks on ARSCHEMA due to the large number of creates in the audit history. What we have in our 7.6.04 SP3 system is the server default is set at 1 and on specific forms we have the form block size set to a higher number (25 on the audit history, 20 on email messages, ...). We also turned off the Status History on our audit history form (since it is always just a create to that form status history is not needed and that eliminates a second SQL insert action for every record). This has eliminated our problem. Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Longwing, LJ CTR MDA/IC Sent: Tuesday, September 11, 2012 9:28 AM To: [email protected] Subject: Re: Changing Next ID Block Size - anything to be aware of? Mary, NM stands for Network Management, but in truth, it is any external system that is generating high volume in a single form, be it Network Management, Web Services, scripts, anything that creates records. I've even blocked myself with multiple escalation threads creating records in the same forms. I would agree with Rick that in 'standard' situations, where you have low volume, and or no automation that creates high volumes of records, you are at little risk of needing this setting. If however you are needing high concurrency of simultaneous submits with some integration, then you may come up against this problem. In your example below you said that you had 10 instances of the script running simultaneously, but were only using 2 threads. I don't know if you realize it or not, but the net effect of your testing was actually only running 2 scripts simultaneously, while the other 8 sat in queue until one of the threads was available, then the next was processed. If you want to truly run them simultaneously, you will need to increase your thread counts to values that allow all instances to run at the same time. With that said, if 10 concurrent is not an actual expected value that NEEDS concurrent processing, then 2 threads should generally be able to handle 10 requests within the specified timeframe without error, but don't confuse yourself into thinking that they are running simultaneously :) To answer your last question, yes, you can change the setting per form in the Form Properties. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
