C
ChUIMonster
Guest
I know Tom is probably going to blow a gasket on this suggestion,but ... Bang! Try cranking -L up to a much larger value and put in more monitoring/alerts/logging to let you have time to find out where the suspects are. Then you can decrease it if it makes sense after the code is changed. It will never get decreased 
But, yes, if this is something that is happening regularly then sometimes you have to make -L bigger so that you can get by while the code is being fixed. On the other hand... Sometimes you cannot make it big enough. This is especially true if the issue is that some coder has decided to use a db transaction to ensure that his year end purge is "all or nothing". And things of that ilk. I find that that sort of thinking is behind an awful lot of these -L problems. The solution in those cases is to distinguish between a "business transaction" and a database transaction. 99.44% of the business transactions like this can be trivially fixed by making them restartable and perhaps adding a flag somewhere to indicate if they completely finished. The other .56% are fixable with a little extra thought and effort. Exactly 0% of them *have* to be coded as database transactions. -- Tom Bascom 603 396 4886 tom@greenfieldtech.com
Continue reading...
But, yes, if this is something that is happening regularly then sometimes you have to make -L bigger so that you can get by while the code is being fixed. On the other hand... Sometimes you cannot make it big enough. This is especially true if the issue is that some coder has decided to use a db transaction to ensure that his year end purge is "all or nothing". And things of that ilk. I find that that sort of thinking is behind an awful lot of these -L problems. The solution in those cases is to distinguish between a "business transaction" and a database transaction. 99.44% of the business transactions like this can be trivially fixed by making them restartable and perhaps adding a flag somewhere to indicate if they completely finished. The other .56% are fixable with a little extra thought and effort. Exactly 0% of them *have* to be coded as database transactions. -- Tom Bascom 603 396 4886 tom@greenfieldtech.comContinue reading...