D
dbeavon
Guest
I figured this out. It wasn't actually stuck, although the symptoms implied that it was: The stack shown for the session (in OEE) remained in the same place for long periods of time. The transaction was open, and the _lock VST table wasn't growing. All the evidence seemed to indicate that the client/server ABL session was stuck. But it turned out that what was happening is the logic was going into an unusual block that was *deleting* lots of records in a loop (well over 100,000 of them). So the stack (in OEE) showed the same line number while the deletes were underway. In my defense, the line number that was displayed was not actually pointing to the DELETE statement - or things would have been a lot more clear to me. It wasn't until about the fifth time I re-read the source code that I figured it out. Those deletes run a bit slow over client/server. They weren't ever a problem when things ran in shared memory (or maybe they would have become a problem if there were even more of them). The lock wait timeout (-lkwtmo 40) didn't apply in this case, because the session was continuing to delete records; it wasn't ever "waiting" on any locks. As a side note, I still wish OE would introduce *transaction* timeouts in addition to the lock wait timeouts. A transaction timeout would be extremely helpful. I don't think that transaction timeouts should be too difficult for the database to enforce, especially for client/server connections. The thing that was probably the most confusing to me was the information in the "_lock" VST. Right up until the end, I was convinced that I would be able to troubleshoot the long-running transaction by watching that particular VST. But it really doesn't show anything interesting in the case of a lot of deletes (its not as if I noticed 100,000 entries for each of the deletes in the active transaction). It always showed a single exclusively-locked record, and seemed to just confirm that the transaction was stuck. I probably should have been using some other VST as well. Thanks for the feedback Gus. I probably shouldn't be so suspicious of client/server ABL.
Continue reading...
Continue reading...