What you need is something that is unique per connected client - and the most "obvious" choice (thread number) can't be used, as there is no guarantee that a single client will use the same thread twice, or that another client won't use the same thread.
One simple way of handling this is to create an instance of the Data class for each connected client. You can then use the instance of the Data class to identify the owner of the lock. You could do this by setting up a connection factory on the server - instead of doing an RMI lookup which returns the one instance of the remote object, you do an RMI lookup which returns a factory which has a method you can call to get a unique instance of the remote object. This unique instance can have it's own instance of the Data class, and so on.
You might then want to think about whether you have a static lock collection, or whether you have a common lock manager class. Likewise you might want to think about whether you have the Data class accessing the database file directly, or whether it calls helper classes to access the database file (so your Data class could become a Fa�ade).
Another advantage of having the Connection Factory is that it makes it simple to handle client's dying later (if you want to do this) - since you have a unique remote object per client, you can use the Unreferenced interface or some collection that uses WeakReferences (e.g. WeakHashMap) to store your locks.