Tatiana, Try this, i. Add getContractors() implementation to Data class. ii. Add getContractors() method to DBAccess interface. iii. Add getContractors method signature to DataBase interface. Here this method should throw either 'Remote Exception' or 'IOException' in addition whatever it is throwing in data class. iv. Provide implementation of getContractors() in Datasource. Hope I didn't mess up with the names... Raj.
Satish, I guess it is a tradeoff between overhead associated with opening a connection vis a vis Resources consumed. As the impact of this choice is mainly on performance, you are correct to say that this is not very relevant for SCJD for which performance is not a requirement. However, I want to be in a position to defend my choice in the documentation and/or essay exam and wanted to see if am making the right assumptions. thanks, Raj
Hi all, I completed my project and presently testing/refactoring the code. One of the things I am debating about is whether to close the db file for every read/write or to close it when closing down the server. I have implemented my solution using RMI and there is a single db instance for all the clients. It seems to me like in a multi user/single data environment, it would result in better performance in closing the connection in the end. Presently I am closing the db file, when I close the connection but I was wondering if there any pitfalls in this approach. Any comments? Thanks, Raj
Satish, There is no record no. in database and I many people(including me)assumed it as an indication of the Physical location of the data. for eg. if the header information is 20 bytes long and each record is 50 bytes long then record 1 will start at position 20 and record 2 will start at 70 etc. There are other approaches to handling this including creating a initial cache collection of records. Hope this helps. If you plan on using the Random() for generation of cookie value, be careful how you do it as it is not gaunranteed that you will get unique values. If you use a long values and increment it, at some point it will exceed the ceiling of long and will give an overflow error. I am using this approach and I am planning to justify this by documentation and also by providing an option for resetting the long value. I remember reading a thread here where people discussed the merits of using the system time as the cookie value(you should be able to find the thread by searching). If you have a fast computer, the algorithm could produce two cookies of same value. There was a workaround to it where you force the algorithm to wait for a millisecond so that the next number is unique. hope this helps. Raj
Satish, I checked again and I think this is what is happenning. There are two rent methods: i. One in DVDDatabse and the other one in ii. DVDDBAdapter. The locking is handled in DVDDbAdapter class and hence the rent method there throws the Interrupted Exception. This is the code I pasted. You are checking the rent method in the DVDDatabase class which does not handle the locking and hence the InterruptedException is redundant here. Max, your thoughts on this?? Raj
Congratulations. Great score!!!. You have done better on locking than most of the people who passed recently. Would it be possible for you to post a high level overview of your design of locking?? thanks, Raj
Derek, I would like to know the answers of most of your questions as it might help me undertsnad the problem I am seeing with synchronization. The answer to question 8, however is below(I am quoting from max's book). Notify() wakes up only one of the waiting threads, which then acquires the lock on the aMonitor. However, notifyAll() wakes up all the waiting threads. Even in this case only one these threads will get the lock to aMonitor. The CPU will decide which of these threads will get the lock and all the other threads go back to waiting state. Since notify() wakes up only one of the waiting threads, there is a possiblility of starvation here as some thread may remain waiting forever. HTH Raj
Hi Max, Thanks for checking my post. I modified my code posting so that it is simple and did not inlcude the logic I had under the while loop to make it infinite. I have executed your code also and I saw the same behaviour. This what I have noticed. Please comment on what you think is happenning. 1. Stared the DVDDatabase program using 'java DVDDatabase' the program started and I see the message indicating that the thread is in synchronized block. 2. At this point the thread above has lock over the static 'reservedDVds' member of the DVDDatabase class. I let run so that this thread continues to hold the lock for the vector. 3. I start another DVDDatabase program simultaneously from the same machine using 'java DVDDatabse'. I see that this thread also entered the synchronized block. How is this possible since the thread in step still has the lock for reservedDVDs. I appreciate your feedback thanks, Raj