LockManager lock/unlock

[Jochen van Waasen]

Hallo!
For record locking I want to use a LockManager class.
When the locking is controlled in this LockManager class is it necessary to implement the lock/unlock in the Data class?
The requirements say that the lock/unlock methods must be implemented. But doesn't mean using a LockManager class that the lock/unlock methods in Data are obsolete?
Looking for clarification.
Kind regards
Jochen

[Mark Spritzler]

If you use a LockManager class then you won't have to implement lock/unlock in the data class, but you do need to say so in your desing.txt and why.
Mark

[Jochen van Waasen]

Originally posted by Mark Spritzler:
If you use a LockManager class then you won't have to implement lock/unlock in the data class, but you do need to say so in your desing.txt and why.

OK, but what is the reason for this?
Is it sufficient to say, that the strict requirements do not allow to modify the method signature of the lock/unlock class?
Jochen

[Max Habibi]

Hi Jochen,
This is one of the few areas where I disagree with Mark: While the LockManager is a good solution, it does not, IMO, adhere to the specific verbage of the exam. If you already have a lock manager that you like and trust, then I suggest that you use it from inside the data.lock method, if your design allows that.
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Jochen van Waasen]

Hi Max!
The requirements says that we must implement lock/unlock methods. For me that means we have to implement them in the Data class. But there I am not able to identify the client (I do not want thread for that, I want to use the 'connection' object) because I can not identify the object there.
Using the lock manager inside the data.lock methods is a very good solution but how can this be achieved?
I want to use the follwing:
Implement the data.lock/data.unlock methods without identifying the client.
Implement a lockManager that is able to identify the client 'connection' object and uses the data.lock/data.unlock to lock the records.
The GUI Client calls the serverclient.lock(record) methods that calls the serverimpl.lockmanager.lock(record, client) methods that stores the (record, client) in a HashMap and calls data.lock(record) to lock the record in the database.
Then I have two lists with the locked records: one in lockmanager with (record, client) and one in data.lock with record. The lockmanager is responsible to locking and unlocking in data class.
Is this reasonable to do?
Kind regards
Jochen

[Peter den Haan]

OK, but what is the reason for this?
Is it sufficient to say, that the strict requirements do not allow to modify the method signature of the lock/unlock class?[/QB]

I would say that that is never a good reason. The requirements are there to guide your choices, but they also represent design choices that are valid in themselves. If you can only justify your design by referring to the requirements, it may signify a problem in the design. For example, if you would implement business methods like book() and findFlights() in Data, it becomes very hard to justify having a client-side object that implements all the public methods in Data. This should set alarm bells ringing.
In your specific case, you need the lock() and unlock() methods in DataInterface, because without them you cannot get booking to work reliably with more than one client. This immediately means that you need lock() and unlock() in Data, simply because Data must implement DataInterface.
The next question is, do Data.lock() and Data.unlock() need any specific behaviour or can you leave them empty? My own line of reasoning was that Data itself can only be used locally, from one single client, in which case you don't need locking [1]. As a consequence I felt it was perfectly OK to leave these methods empty in Data.
- Peter
[1] That was a bit too glib. In theory, it is possible that you might need to use a local database from multi-threaded code where threads compete with each other for locks. The Data class as I described it won't work in that case; however, if coded properly nothing prevents your networked classes from being used locally, and they would work with multiple competing threads. If you extended UnicastRemoteObject, such code will open a couple of ServerSockets, but that seems a small price to pay for simplicity.

[Max Habibi]

I think your approach here really depends on if you consider yourself a a software craftsman, or a software artist.
Me, I'm a craftsman.
My Job is to what the client wants. I may attempt to get him/her to change their mind on what they want, but they get the final say: If they want an ugly product, then they'll get the best damned ugly product I can make.
None of this, however, is relevant to the SCJD.
Your assignment, should you choose to accept it, is to do the assignment exactly as given, with no option of appealing to the client(in this case, Sun Ed). Most of the other SCJD specialist I know agree here: though some, of course, will not.
The final analysis is this. If you don't implement the assignment exactly as given, then you're not doing exactly what you were asked to do, and Sun is morally (and practically) in the clear to fail you.
however, there have been people, including the moderator of this forum, who have done if differently, and done well on the exam.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4