With every advancing version of Synergy/DE we are better armed to tame the beast! For me one of the biggest beasts in a commercial application is a record lock. This beast will appear without warning, leave no trace of its being, and always instils rage in the innocent users of the system who encounter it.
Although locking records is a fundamental requirement of any application it is always difficult to explain to a user who has been sat there for ten minutes with a “record locked” message flashing on the screen that “the system is functioning correctly”. All they want to do is move forward and finish the task in hand.
So who has that rouge record locked? Which line of code is actually causing the lock? Is the lock valid? How long has the lock been there? If we could answer these questions then life would be so much easier. So how can we tame the record lock beast? With Synergy 9.5.3b of course!
If you attended the DevPartner conference in either Chicago or York then you would have seen my presentation “Hooked Line & Sinker”. During the session I presented the new (and extremely cool) IO Hooks class that allows you to hook methods to the various events that occur around SDBMS data access. For example you can register methods that are executed every time a record is read, stored, updated or deleted. And given this capability I demonstrated the beautiful Synergy DBMS Lock Viewer. By assigning my LockRecorder class to every file opened in update mode (a single line code change to my standard file open routine) I was able to record lock information in a central “lock manager” control file. The Synergy DBMS Lock Viewer program I wrote then reads this file and displays lock information.
And the real beauty was just today. Having modified a customer’s application to utilise the LockRecorder class I was able to run the Lock Viewer:
And immediately identify who was locking which records in which programs and how long the locks had been there. It’s beautiful to just sit and watch the lock information appear and then clear – and when they don’t clear we call the culpritJ. The usual response was “I just nipped out to get a cuppa”. Maybe not the users fault, but now I know where to look in the program to see if I can prevent the lock being required.
If you are interested in the example code you can use the “Knock Knock Who’s Locked” tutorial which steps you through the whole process of creating the LockRecorder class and monitoring the lock manager control file. The tutorial, along with all conference tutorials, can be downloaded from http://tutorials.synergex.com/.