This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
hello boys and girls, i have some problems interpret the assignment, please let me know if u can help... thanks good day to all Question 1 ========== "Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the DB interface provided above." Is that mean that if in a network mode -- the class that i use to implement DB interface, which is call "Data". it need to be multi-instances; one instance per client. ?? Question 2 ========== A file called choices.txt that containing pure ASCII text describing the significant design choices you made. How many words is consider ideal for this choices.txt and Do i need to describe the benefit of RMI like what some of the book has describe? 6_6 thanks
Question 2 first. It depends. It all depends on how much you want to say. Now a short "I chose RMI instead of sockets" won't do. You need to include some pros and cons. Basically defending your design choices. So anywhere you feel you made a "Design choice" document it and explain why you made your choice. While the length of this document is not stated and what one persons document size is to another makes no difference. At least that is what my wife tells me. Mine was 5 pages.
Question #1. Tought to answer since you are a little vague in the question. But here's my attempt. There will be only one Data class on the server, now the Remote implementation of the interface that the client gets as its proxy. Yes there will be one object for each client, and you will be able to use it as the client identifier for your locking design. Mark
I think it is not "multi-instances" but something like "multi-threads".
Joined: May 03, 2003
"Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the DB interface provided above. ================================================== i have provided only one instances of Data sharing across clients. Not all the method in Data are synchronized ie. update,delete,read will be synchronized. And lock and unlock will not be synchronized. (does it mean concurrent requests is provided?)
I have provided only one instances of Data sharing across clients. Not all the method in Data are synchronized ie. update,delete,read will be synchronized. And lock and unlock will not be synchronized. (does it mean concurrent requests is provided?) Well, what happens if two clients try to lock() the same record at the same time? Without some sort of synchronization, isn't there a good chance they'll both succeed in "locking" the file? (Except one will turn out to have an invalid cookie, probably). The case of the unlock() method is a bit more complicated to understand the things that could go wrong, but I really think you should synchronize this too. And create() - what if two threads create a new record at the same time? Isn't there a chance that they will both put the new record in the same location at the end of the file? Some synchronization is necessary in all these methods, I think. Note that there are a number of different ways to use synchronization, and you don't necessarily have to synchronize the whole method in each of these cases. Short synchronized blocks around a few key operations are often good. And there are several choices about what you use as a monitor for each synchronization - you may find this discussion useful. (And probably many other past discussions here.) But I'm pretty sure you'll need some synchronization in each of these methods. It's also possible (I think) that you could leave all Data methods completely unsynchronized, and instead manage concurrency through some other class that controls access to Data. But most of us are putting the synchronization in Data itself, and once you're synchronizing read(), update(), etc. in Data, you really should handle them all at the same level.
"I'm not back." - Bill Harding, Twister
Joined: May 03, 2003
First of all thanks for your reply. ================================================= i have provided only one instances of Data sharing across clients. Not all the method in Data are synchronized ie. update,delete,read will be synchronized. And lock and unlock will not be synchronized. (does it mean concurrent requests is provided?) ================================================== 1.really sorry for the confusion. what i am trying to said is i had synchronized update, delete, create lock and unlock, methods that i haven't synchronized are the read and find data, (try to allow "concurrent requests" while other accessing synchronized methods). the reason that i do it this way is simple b'coz the read and find data will be ok to have multiple access to the ArrayList at the same time. so, please tell me what do u think.
Joined: Jan 30, 2000
Well, depending on how you do the update() exactly, you may need synhronization on the read() and find() also in order to see records without some odd errors. E.g. what if a record has field values "1", "2", "3", "4", "5", "6" and you update it to "A", "B", "C", "D", "E", "F" and at the same time, you're trying to read it. If your update() method is changing fields one at a time, your read() may see
"1", "2", "C", "D", "E", "F" for example. Is this acceptable? Not sure, but I prefer to avoid it by either synchronizing the read(), or writing my update() so that all fields change simultaneously. You'll have to anyalyze your own code to determine if this is necessary.