N
Nigel Allen
Guest
Greetings Moving on from my earlier questions (that some kind person marked "answered"). The system I am working on at the moment has a .net application that talks via an appserver to a front end OO ABL program that talks via another appserver to another OO ABL program that accesses the database (please don't ask me why). The problem is that for at least 3 years (possibly longer), there has been a gradual build up until the internal appserver agents start to crash and the external report a 3244 error (too many temp-tables). Given that the "too many" is 32767, I suspect that there might be an issue 
After the system (and the appservers) are restarted, the problem goes away... For a while. I've narrowed the problem down to one single temp-table that is used in just about every single transaction in the system. The external programs repeatedly run a back end program to check on a user's and customer's credentials. To put it in context, looking through the external appserver's log I saw that the credential checking program was run from the external app some 226 times in less than a minute (it's a /very/ busy WAN based system). I've checked for any dynamic temp-tables right across the entire system - there are none. I've checked for persistent procedures right across the entire system. There are only two and neither of them use the table in question. One of the things that is bothering me is having the two appservers in the equation - not something I'm familiar with. The external one runs as state-free whilst the internal one runs as stateless. Is it possible that the internal appserver (the one that fails) is somehow not cleaning up the temp-table? It looks like every time the object that defines the temp-table is instantiated, it is somehow "staying there" and adding to the load until it eventually crashes. Has anyone any experience with this type of setup? Anyone who would like to suggest any possibilities I should be focussing on? TIA Nigel.
Continue reading...
After the system (and the appservers) are restarted, the problem goes away... For a while. I've narrowed the problem down to one single temp-table that is used in just about every single transaction in the system. The external programs repeatedly run a back end program to check on a user's and customer's credentials. To put it in context, looking through the external appserver's log I saw that the credential checking program was run from the external app some 226 times in less than a minute (it's a /very/ busy WAN based system). I've checked for any dynamic temp-tables right across the entire system - there are none. I've checked for persistent procedures right across the entire system. There are only two and neither of them use the table in question. One of the things that is bothering me is having the two appservers in the equation - not something I'm familiar with. The external one runs as state-free whilst the internal one runs as stateless. Is it possible that the internal appserver (the one that fails) is somehow not cleaning up the temp-table? It looks like every time the object that defines the temp-table is instantiated, it is somehow "staying there" and adding to the load until it eventually crashes. Has anyone any experience with this type of setup? Anyone who would like to suggest any possibilities I should be focussing on? TIA Nigel.Continue reading...