I may not be following your design, but it sounds like the client's are not allowing themselves to call unlock if they don't currently have the record. This is a clever idea, and a practical one.
However, it does not meet the requirements of the unlock method, as they were presented to me. That is, my unlock method (in the data class) required that the calls be ignored if the person attempting to unlock didn't actually own the lock. That's not what's happening in your case: in your case, your just promising that the client will not try to unlock records that they don't own. In the requirements (as I understand them), this responsibility falls on the Data class. You've deferred the responsibility to the client. It's a subtle, but important, difference.
If you decide to consider another approach here, then you'll need to provide some way for the Data class to keep track of the clients doing the locking. This will likely suggest the usage of a Map of some sort. This can be either through a ClientID, or, if each client gets their own thread, the ThreadID. I recommend the latter.