• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Recognizing the Owner of a Lock

 
Adam Nace
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been puzzling over this for quite a while. The interface I was provided with (DBMain) provides a lock and unlock method that take as parameters only the record number, and supply no return value.

The update and delete methods require a lock be held by the client who invokes them, but do not provide a parameter that can be used to specify the client who invokes them.

I see a lot of people here have used implemented a lock routine that provides a unique "cookie" each time a record is locked, that they must then provide when modifying, deleting or unlocking a record.

To me, this means that they are NOT following the contract specified by the DBMain interface. The way I read the assignment is that one should be able to hold a reference of type DBMain to the database and everything should work correctly.

If I continue with this interpretation, I can think of only two ways of differentiating between clients:

1. If I use a socket approach for my networking, I can differentiate between clients by identifying the thread that the request came on.
2. If I use an RMI approach for my networking, and make Data extend the RemoteServer, then I can determine the host name from which the request was sent (which wouldn't work so well if the host was proxied?).

This means I need to specify that the Data class is only suitable for one or the other approach, and NOT suitable for any other implementation, which to me, indicates that it does not obey the contract of the Interface, which does not specify specific suitability for either.

Any comments?

- Adam
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There was quite a discussion about that about 2 months ago, which led me to redesign my entire locking system (to something that's probably way overengineered for the requirements provided).

Essentially I pass the factory for my database connection a callback method which provides an interface to uniquely identify the client using a sort of session ID created by that factory and passed on to the client application.

That session ID should be unique enough, consisting of the IP address of the client, a nanosecond precision timestamp (or as close as the JVM can get, which should be a few microseconds at worst), and a random number.

That way multiple clients on the same IP address can connect to the database and still be uniquely identified.

When a client tries to lock a record, the locking mechanism gets handed the callback method by the proxy which controls database access and calls the interface to get the session ID.
It combines that with the timestamp of the lock event and the requested record ID, and if the record is available for locking stores all that data and the cookie and returns the cookie to the proxy which forwards it to the clients.

When the cookie is then used, the reverse happens. The proxy passes the record ID, cookie, and callback method to the locking system which uses it to look up the cookie and verify that it really belongs to that record as locked by that particular client.

As I said, it might be overengineered
 
Adam Nace
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hmmm... I'm not sure I understand why you need a cookie for the lock when you have a unique session id for each client.

I'm also not qutie sure how your proxy idea is working. I assume that when you request a lock, you first identify yourself to the proxy? Then when the Data.lock(int) method is called, it requests the id from the proxy? Then I assume that your are synchronizing on the entire Data object before passing in the ID, and acquiring the lock?

anyway, it seems like people are getting passing grades for that sort of design, so maybe I'm making too much work for myself, but it seems to me that if you strip away your proxy mechanism, your locking solution would not work.

the way I read the instructions makes me beleive that one could theoretically remove ALL classes from your application except for DBMain, Data, RecordNotFoundException and DuplicateRecordException, write a VERY simple command line client application, and your Data class should still perform to specs. Everything else would be networking code, ui code, optimization proxies, simplification proxies, etc.
 
Adam Nace
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I have a solution now. It sort of uses a proxy idea as well. Thanks!

- Adam
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic