They have DvdFileAccess class that controls access to the actual file where the data is stored, all instances of this class are meant to refer to the same file, and the constructor they have is outlined below.
The "if" statement seems odd - because it will always evaluate to true, so why have an "if" condition there in the first place. The database member variable is an instance variable, so when invoking the constructor the condition will always be true - the database variable will always be null at this point in the constructor.
So the code that creates a new RandomAccessFile will always be invoked when the constructor is called, and the "else if" portion of the code will never be executed. Unless I am misunderstanding something?
It seems to me that the source code associated with the book is incorrect, whereas the the code in the book itself is correct, it's on page 139 if anyone has the book. What do you guys think?
The constructor of the DvdFileAccess class as specified in the book:
Maybe in the website source there is just a static keyword missing (to make database a class member). I agree that would not be very decent code, but maybe it's just to make you think about every line of code (instead of just blindly copying/pasting sources from the book). So I would say: mission accomplished Maybe it's just an old version of sources being downloadable from the website (and maybe it's mentioned in the errata page)
I had checked the errata, but I couldn't find anything in relation to this.
The source and errata are downloadable from here http://apress.com/book/view/1590595165
Roel De Nijs wrote:maybe it's just to make you think about every line of code (instead of just blindly copying/pasting sources from the book). So I would say: mission accomplished
My impression is that this applies to a good bit of the code in that book. Some of it is overwrought. Some of it is too austere. Some of it is incorrect. I have assumed that all of this was intentional so that the book wouldn't simply dish up a complete serving of Finished Assignment™.
But I don't think any author could claim that incorrect code\solutions were left in to make the reader think ! Fair enough in an exercise, but in the main text of the book, an incorrect solution merely distracts someone who notices it away from the main train of thought.
Sean Keane wrote:But I don't think any author could claim that incorrect code\solutions were left in to make the reader think !
Thanks for finding that thread, Roel! I hadn't seen it in a while.
Sean, this is what I meant by 'incorrect'.
My intention is to follow the book from beginning to end, understanding all the code, and noting down the main areas that need to be thought about with regards how the application is designed and implemented. I've also been reading this site which has mountains of information, so I'm noting down some thing I read in posts too. Then my intention is to then start off from scratch myself with my own design\implementation.
So all I was really doing here was questioning the code\design as I'm going through the book trying to understand "how does this work?", "is this a good design?", "is this a good implementation?".
On the thread you guys linked to, Andrew says himself that they wouldn't have deliberately added bugs to the code, which is reassuring to hear , so I think I will mail him on my findings and maybe he can update the codebase for the book.
Cheers for the help.
Below is the method that is used to write to the file. But I'm happy I understand this now, and based on the code from the book my concern about the file being corrupted would not occur. Does this sound correct?
As far as I understand the code your assumption is wrong. If a new instance of DvdFileAccess is created, a new RandomAccessFile instance (with different path) will be created, but the old instance will still have its own RandomAccessFile instance, because database is not declared static, so no corrupting of a database file.
On the purpose of the book. 100% agree, it should be viewed just as a reference. Which is what I am using it for. This thread was just to get some help\opinions as I was not quite sure if the code was correct or if something was amiss.
From my opinion, if "database" is not static this code does not make much sense:
Both should synchronize on the same object, or else one client might update a record, but other clients might see stale values when reading the same record from the database.
Alexandru Dragoi wrote:So in conclusion "database" variable must be static, isn't it?
That's not really required. Just 1 unique instance is required. One possible solution would be to make it static, but you can also ensure there is just 1 instance created of the class containing the database variable.
So my affirmation:
Every client has its own instance of DvdFileAccess on the server side.
So in theory, it should be only one object that is used to access the database.
But in practice we can imagine this scenario:
1. Client1 is in the middle of reading a dvd from the database. For that it will use database object reference variable which refers to object DvdFileAccess1
2. In the same time Client2 connects to the server. It will update database static reference variable to point to a new object : DvdFileAccess2. Needless to say that this reference variable update has no effect on Client1 read opperation. Client1 still uses DvdFileAccess1 object to read from DB, because it did not even started reading (a context switch happened for example right before Client 1 was about to start reading).
3. Client 2 modifies a record in the database.
The problem that I see here is that DvdFileAccess1 and DvdFileAccess2 objects are using different locks to access the database (RandomAccessFile1 and RandomAccessFile2).
Reading/writing to the database file doesn't seem to be atomic.