Lock/Unlock not in Data class..ok??

[Pallav Grigo]

Hi...I have another question about lock/unlock..I have implemented these methods in my Server class instead of Data..Server keeps track of all the clients and has the getConnection() method to return unique RemoteData objects..Did anyone lose marks for not putting these methods in the Data class? Appreciate all responses.
Regards,
Pallav.

[Sai Prasad]

As per the requirement, Record locking must be implemented using the methods public void lock(int) and public void unlock(int). I am implementing the lock/unlock in the Data class for this very reason. I remember reading other posts about having it in the LockManager or someother place. I don't know the implications.

[Geir Morten Hagen]

I do not fully agree on implementing locking in Data. As noted in several other threads; locking is not necessary when running in local mode. That's why I use a LockManager, which is called from the remote object to lock and unlock records. When running in local mode, the remote object is not in use, then I just use Data directly. I just left lock and unlock in Data empty, or well lock just validate the record position and throw an exception if it's invalid.

[Adam Roberts]

I'm guessing Sai is correct here, you most likely need to put the method implementation in the Data class or helper class(ie LockHandler, etc). Regardless, it seems this should be part of the database rather than the server.
That being said, I believe you can do something similar with the connection objects etc. You can identify the clients at the server level and the pass on the locking part to the Data class.
Also, if your locking device is stable, there should be no problem with a local client locking/unlocking records.

[Sai Prasad]

I am using LockManager at the server level only to validate the client to get access to lock/unlock/modify/delete methds. LockManager is on the server side to manage mutiple access by clients which is the function of RMI server.
Blocking and notification takes place in the Data class in lock and unlock methods. I could not come up with a design to satisfy the requirement which I posted earlier and keeping lock/unlock methods blank in the Data class.

[Pallav Grigo]

Thank you very much for your responses..they were very helpful...I still have some doubts..currently I have a Hashmap object to keep track of all the locks and their owners...This object is a member of my server class..if I were to implement locking in the Data class, then I would have to define new methods in the Data class regarding the handling of the locking..and I read in some other posts that people lost marks for defining new methods.. I think it was Mark Spiltzer...Is it still viable to put these methods in the Data class?
Regards,
Pallav

[Mark Spritzler]

Peter, in his submission had lock and unlock in the data class, however they were empty. He moved them to the LockManager.
I would try to avoid adding any new methods to Data class in fear that it might have an effect on your marks.
There are other ways to create a nice clean design without having to add any extraneous methods in the Data class.
I did hypothesis that that might have been one of the reasons for losing points, but of course none of no the exact reasons why anyone loses points.
Well except for Sai who goes overboard and builds the Taj Mahal. JK
Mark
[ May 03, 2002: Message edited by: Mark Spritzler ]

[Nigel Browne]

I created an innerclass within Data called LockManager. The lock/unlock methods forwarded the method calls to the innerclass. In my remote implementation I call Data lock/unlock, in local I have empty method bodies.
I used HashSet instead of HashMap fyi.

[Mark Spritzler]

Just a question, since I didn't have a LockManager, but I am always curious as to the actual design. But wouldn't you create your instance of the LockManager in the ConnectionServerEngine that is bound to JNDI, and just pass a reference to it, along with the reference to the Data class, then the RemoteImplemenation class can call and use the LockManager, without ever touching the Data Class?
Mark

[Sai Prasad]

I wouldn't desing the LockManager as the inner class of Data since I need to modify the lock/unlock in Data to pass the remote object to map the the locked record to the client.

[Mark Spritzler]

I wouldn't desing the LockManager as the inner class of Data since I need to modify the lock/unlock in Data to pass the remote object to map the the locked record to the client.

Do you mean you would need to modify it if you used an inner class in the Data class? If so then you are right.
That would be ugly. The Data class should know absolutely nothing about the Connection Class, or really the LockManager. If you put your LockManager in the Data class, then why not just not have it and implement the lock/unlokc directly in the Data class.
Mark
Mark
[ May 03, 2002: Message edited by: Mark Spritzler ]

[Nigel Browne]

Originally posted by Sai Prasad:
I wouldn't desing the LockManager as the inner class of Data since I need to modify the lock/unlock in Data to pass the remote object to map the the locked record to the client.

Why would you need to modify ? I don't believe that adding synchronized to a signature is modification

[Sai Prasad]

Adding synchronization keyword to lock/unlock methods is not just enough to map a client to a locked record. You need to have a mapping between the remote object and the locked record which is not possible if you implement the LockManager as the inner class unless you change the signature of the lock() and unlock(). I wouldn't do change the signature of lock() and unlock() methods.
Moreover I agree with Mark on implementing the locking mechanism in lock/unlock methods if you are going to have an inner class LockManager.
[ May 03, 2002: Message edited by: Sai Prasad ]