search

intersystems / TestCoverage

Test Coverage Tool
MIT License
9 stars 8 forks source link

Lock table issues collecting coverage data #1

Closed timleavitt closed 6 years ago

timleavitt commented 6 years ago

Working with a customer at Global Summit, we found the lock table filling up when collecting coverage data at the end of runs. Independent of locksiz/gmheap/escalation threshold, insert/update at the end of a run should use %NOLOCK %NOCHECK for performance.

daledupreezISC commented 6 years ago

@timleavitt, did you manage to narrow down the issue to the call to ##class(TestCoverage.Data.Run).MapRunCoverage(tRunIndex) or to ##class(TestCoverage.Utils).AggregateCoverage(tRunIndex) from TestCoverage.Manager::OnAfterSaveResult()? Or was even that not clear from your investigations?

timleavitt commented 6 years ago

@daledupreezISC I believe it was in MapRunCoverage.

timleavitt commented 6 years ago

I got another report of this from a user at InterSystems:

Collecting coverage data for all tests: 
  TestCoverage.Manager:OnAfterAllTests begins ...
LogStateStatus:0:TestCoverage.Manager:OnAfterAllTests:ERROR #5540: SQLCODE: -110 Message: Unable to obtain lock on table 'TestCoverage_Data.CodeUnitMap' to check uniqueness of constraint 'Reverse'  <<==== **FAILED**
TestCoverage.Manager:OnAfterAllTests:::
  TestCoverage.Manager:OnAfterAllTests failed
timleavitt commented 6 years ago

Fixed.