D
dbeavon
Guest
We are eager to try some new things when our OE database finally moves from HP-UX to Windows. One database feature I'd like to try is a timeout that enforces limits on client connections (via "ClientTimeOut" see Progress KB - How to use the ClientTimeOut Startup Parameter. ) We frequently have long-running transaction issues. I accept that it is normally a programmer's responsibility to fix this. However there are times when an ABL programmer has no means of disconnecting from the database or the transaction. It follows that the database *server* should have some responsibility as well - in preventing a client from connecting for hours at a time (especially while holding locks). I'm eager to hear if anyone has any real-world experience with the "ClientTimeOut" feature. A possible use for the feature came up again today. A small amount of ABL code was running in a single session, and it locked a few records, and proceeded to open a JMS adapter session to send the data to a queue. However, the JMS adapter became hung (as a result of a Progress bug), and was not able to proceed nor to fail. It caused a series of cascading issues as other ABL transactions started trying to lock the same database records. This lasted for HOURS until an OpenEdge DBA was able to intervene and kill the misbehaving database connection. (... for more on that scenario, please reference the following thread: JMS generic client stuck since yesterday. - Forum - OpenEdge Development - Progress Community ) It seems that the "ClientTimeOut" would have alleviated the related locking issues in the OE database. The misbehaving ABL session would have continued to remain hung by the JMS adapter ... but at least the database server should be able to cut itself loose. The fate of the entire database shouldn't depend on what is happening within a single misbehaving ABL session!
Continue reading...
Continue reading...