We have a 3rd-party application which is sporadically leaving connections in a sleeping state with an open transaction. This is causing many other queries to be blocked. I've been logging sp_WhoIsActive to a table, and below is the lead blocker. I believe the Java application is using Hibernate ORM.
The query is against a very small table with just a few thousand rows. If I run this statement manually, it finishes immediately. The query in my sp_WhoIsActive table shows NULL in the wait_info table, and 10 million reads, which sounds suspicious. I force statistics updates every day on the entire database as we've seen hundreds of millions of reads on similar small queries in the past. That seems to have helped, but this still doesn't sound right.
How can I troubleshoot this to see what's happening? The record does not show the execution plan.
(@P0 decimal(38,0),@P1 decimal(38,0),@P2 nvarchar(4000))DELETE FROM
SCHEDULE WHERE (PROCESS_ID= @P0 AND PARENT_ID= @P1 AND SCHEDULE!= @P2)
Best Answer
Been there 10+ years ago, here's what we did
We had the same issue with Kronos/Payroll. It get's pretty serious when people cannot get their paycheck. Like yourself, I narrowed things down to open/sleeping transactions and it was Java related as well. What's more when we contacted the vendor, they refused to take any responsibility for it. So we internally had to find a solution. I reviewed the vendor API and it definitely looked like the issue was on the vendor side.
In my case, which MAY not be your case, I discovered by working with the payroll staff that these open sleeping transactions had actually completed their work. So we implemented the following job that still looks for these processes and kills them to this day.
Basically, a T-SQL job shown in Listing A calls stored procedure in Listing B to kill the open/sleeping transactions, and the data about these issues is stored in Listing C. My apologies for any legacy T-SQL faux pas you may find--this code is crusty. Please try it in your dev/test environment first to see if it works for you. Just talking about killing these is just as creepy today as it was then--I don't like it.
Oh yes, the kicker for us all is that killing the open/sleeping transactions did NOT roll them back--but allowed them to complete (as well as stop all the blocking chains). My guess is that they were not programmed correctly to be distributed but rather they programmed the app and SQL Server to be on the same server.
Listing A: T-SQL job killing open/sleeping transactions (first four lines should be commented out)
Listing B: the sp_kill2 stored procedure looks for open/sleeping transactions and kills them
Listing C: Processes3 table contains data about the sleeping/open transactions