Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Design review and thread-safety

 
oli renard
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello everyone,
I currently have the B&S 2.1.1 exam and I would like to have some comments on my design, please.
My Data class implements the DB interface as per the requirements. The Data class is not a singleton and none of its methods are synchronized. None of the methods are thread-safe per se. I have a suncertify.business package which contains business-layer object, including an interface called DBContractor. There are 2 implementations of this interface, LocalDBContractor and RemoteDBContractor. In the latter (namely, in remote mode as I am not concerned about local mode), my intention was to use code as follows, for the update functionality:

The recordLockManager is a static reference to an instance of a class called RecordLockManager that locks and unlocks records on the database. In that sense, I do not even call the lock or unlock methods in the Data class as these are taking place at a "higher" (business-tier) level. Note also that the RecordLockManager can lock and unlock records in a thread-safe fashion as all its methods include sinchronization around a static reference to a HashMap.
My understanding of the application is also that when the RMI server is started, there is effectively only 1 instance of the Data class on the server. Hence, I have reason to believe that all my code is thread-safe. Looking at the code in Max Habibi's book, I see that most methods in the DVDDatabase class are synchronized (the reason for which I still fail to undertsand).
Can someone please help me determine whether my design is both thread-safe and correct?
Thank you
 
Satish Avadhanam
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Renard,
Originally posted by oli renard:
Hello everyone,
The recordLockManager is a static reference to an instance of a class called RecordLockManager that locks and unlocks records on the database. In that sense, I do not even call the lock or unlock methods in the Data class as these are taking place at a "higher" (business-tier) level.

I think the lock and unlock methods that are given in the given interface should be used in the locking mechanism. I mean if you don't use them, then all you are using from the provided interface are "update" to book a record and maybe "find" to search. Its just my opinion. Some ranchers even thought(and discussed this issue in detail some time back) that as the lock/unlock methods are made public, they must be exposed to client. I think you should wait for other's opinion this who already took the exam. What I don't understand is how are you using locking mechanism in the business layer without involving the lock/unlock methods from the Data? Oh I think in B&S assignment there are no cookies involved. So your locking mechanism would be completely different than mine(URLyBird).

Note also that the RecordLockManager can lock and unlock records in a thread-safe fashion as all its methods include sinchronization around a static reference to a HashMap.
My understanding of the application is also that when the RMI server is started, there is effectively only 1 instance of the Data class on the server.

If there is no connection factory, then only single instance of the class which you registered in RMIRegistry is present. So all the requests will eventually get a single reference to your Remote interface to use.

Can someone please help me determine whether my design is both thread-safe and correct?
Thank you

Let's wait and see for fellow ranchers who already passed, to comment on the design
 
Nathaniel Stoddard
Ranch Hand
Posts: 1258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I don't think anybody here will be able to definitively tell you whether your code is thread-safe or not, since you can't post it all.
Perhaps you should start by asking yourself:
1) What methods ARE thread safe?
2) Will they function correctly as the user expects when there are many remote clients using the system?
If you're record locking is indeed thead safe, and operates as the users expect, then it reasons that your application is in good shape.
Note: you should make an extra effort to make it very evident that this is the case, since the grader won't spend forever analyzing your code to ensure it's thread safe.
 
oli renard
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your comments Satish.
You probably have a point regarding the lock/unlock methods in the Data class and I do need cookies in my assignment.
Also, I do intend to use a connection factory. however, my point was that even with such a factory, there will only ever be a single instance of the class in the RMI Registry. Since this is the case, then no methods in the Data class need to be synchronized if the RecordLockManager handles the synchronization around the record locking and unlocking. This is why i fail to understand why most methods are synchronized in the DVDDatabase class in Max's book).
Thanks for your input and I would be extremelly grateful to hear from fellow ranchers.
Olivier
 
oli renard
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your feedback as well Nathaniel.
My intention was to make it clear in my design decisions document that the Data class is in fact not thread-safe and that the only way to access the database in a thread-safe manner is to use the classes defined in the business tier. Whether this is sufficient or not for the grader, I do not know.
Olivier
 
Nathaniel Stoddard
Ranch Hand
Posts: 1258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would have to say that insisting that the user use the business classes to ensure thread-safety is in error. People have been debating the whole 2-tier versus 3-tier thing forever ....
You definitely want to make sure that IF a client was able to use your Data class exclusively it would be thread safe for multiple clients. After that, I think it's perfectly acceptable for you to use the business classes or whatever you want to make sure the rest of the requirements are fulfilled.
In my case, I used a 3-tier approach, but all synchronization was done through the Data class. (And I passed).
Hope that helps more -- I was a bit confused about what your connection factory is creating .. but maybe that's a different question.
 
oli renard
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for this Nathaniel. Your comments probably mean that I am going to have to revise my design considerably. But that is part of the exercise, I guess.
However, your comments also make me realise that if your Data class is thread-safe then that must mean that when used in standalone mode the single client must be paying a performance penalty for the unnecessary/unrequired synchronization that is part of the Data class? Or do have the wrong end of the stick?
Thank you
 
Nathaniel Stoddard
Ranch Hand
Posts: 1258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, in the URLyBird assignment, the specs demanded that we use the same Data class in both execution modes, so we didn't have to worry about it.
In your case, either way, I think the performance hit is negligible for the standalone user. It's certainly going to be faster than using the database over the network, and since there's never going to be a blocking operation, I'm sure she will be just fine with its performance.
 
oli renard
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Nathaniel. I have been thinking about your previous post and can you please explain why I would want this to be the case:
You definitely want to make sure that IF a client was able to use your Data class exclusively it would be thread safe for multiple clients.

I have not seen in any specs that what you stated had to be done. I am possibly completeley off the mark here, but I thought that my design would quite nicely separate responsibilities. The Data class would manage the access to the database while in the middle tier (what I referred to as the business layer earlier) would ensure that the proper lock manager would be invoked prior to making the calls to the Data class.
Oli
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic