File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Questions about DvdFileAccess (code from the book) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Questions about DvdFileAccess (code from the book)" Watch "Questions about DvdFileAccess (code from the book)" New topic
Author

Questions about DvdFileAccess (code from the book)

Oguz Ozun
Greenhorn

Joined: May 10, 2007
Posts: 19
Hi Ranchers,

I have a few questions about the sample code given with the book
(SCJD Exam with J2SE 5, 2nd Edition). My questions are all related with
concurrency.

1. In the constructor of DvdFileAccess class, there is such a if statement:



As you see, this if statement prevents reassignment of the database object. If it is initialized before, do not initialize it again and for consistency, the given path (as a parameter) is checked with the path supplied before.

My question is that isn't there any possiblity of 2 or more threads can execute statements belonging to if? Shouldn't we put one more check after if statement? Something like (I do not know, just suggestion)


Most probably, I am missing something and I am wondering what it is


2. My second question is that in DvdDatabase class,



database field defined as static; therefore, it is shared by all objects of DvdDatabase. However, in the constructor of DvdDatabase class, for each instance of DvdDatabase class, it is reinitialized/recreated. I mean actually it is shared by all objects of DvdDatabase but for each newly created instance, it is reinitialized/recreated. Is there any particular reason of this behaviour or am I miss interpreting something on the solution?


If I am wasting your time with those questions, please accept my apologies
Thanks in advance for your comments ...

[ December 06, 2007: Message edited by: Oguz Ozun ]
[ December 06, 2007: Message edited by: Oguz Ozun ]
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

For you 2nd question, where it gets recreated every time in the constructor..
Could it be that this code will only get called once since it is protected with a synchronized block in a getInstance() method ?

But then, the constructor should be "private" instead of "public".. You can still check for the getInstance()...

Regards,
Alex
[ December 07, 2007: Message edited by: Alex Belisle Turcot ]
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

for your first question, unless I'm missing something, the code is in the constructor, the check is on a private (non-static) method.

2 threads executing this code would be in different instances (soon to be created)..

IMO, there would be no concurrency issue there.

Regards,
Alex
Dmitri Christo
Ranch Hand

Joined: Jan 19, 2007
Posts: 81
Hi Alex, I have the same concern with Oguz regarding his 2nd question about the DvdFileAccess constructor. IMO he has a valid argument.

Just wondering, where would the caller be? I mean, you explain about a synchronized block and a getInstance() method. Would that be in the client for example or elsewhere in the code from the book?

Many thanks for explaining this a bit further.
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

I looked back at the answer to the first question

My question is that isn't there any possiblity of 2 or more threads can execute statements belonging to if?

Shouldn't we put one more check after if statement? Something like (I do not know, just suggestion)


I found your example is Monk's book (p139). He specifically mentions that :

"Although the DvdFileAccess class is not a singleton..."


Perhaps it's one of those "should not be too close to your real assignment". He points out that Singleton would

be nice, but not what he implemented.

And for sure, without the synchronized block / singleton, I would say it is not thread safe.

Also, you can see that his DvdFileAccess class is of "package" visibility, so maybe he handles the concurrent

access at a higher level..

He also mentions at p138:

In addtion, if we were to make the DvdFileAccess class a singleton, any class that uses the DvdFile Access class

would have to be coded differently than if it is a standard class - if we were later to decide that the same class can

be used to process multiple data files (with some simple modifications)...

...
As mentionned earlier, DvdDatabase is the facade through which all other classes should access data,. Therefor, no other classes should call DvdFileAccess directly.


So, he really handles the concurrency from its the calling class instead.

Regards,
Alex
[ December 14, 2007: Message edited by: Alex Belisle Turcot ]
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
For the 2nd question

Just wondering, where would the caller be? I mean, you explain about a synchronized block and a getInstance()

method. Would that be in the client for example or elsewhere in the code from the book?


Ok, having the example in front of me, the assumption that it might be a singleton implementation is wrong.

Definitly, the code is not thread safe, but again you have to consider he has a distinct chapter on "threading"..

Nevermind this code I would say, you realize there is a thread issue, so you could decide to implement DvdFileAccess as a singleton.

Here comes your question, when using a singleton, to make sure no 2 thread instantiate your object, you define your constructor as private. You then provide a public static getInstance() method. In that method, you use a synchronize block to make sure only 1 thread is executing, and you instantiate it.. you keep the reference internally with a private static reference to itself..

So you could do something like the first poster suggested:

[ December 14, 2007: Message edited by: Alex Belisle Turcot ]
Dmitri Christo
Ranch Hand

Joined: Jan 19, 2007
Posts: 81
Thanks for elaborating Alex,

Your explanation certainly makes sense and would be a sound way to implement the functionality we are discussing here.

If we look at the caller class (DvdDatabase) the author states: "One instance of this class should be created for each connected client. The instance of this class can then be used to identify the client to the reservations module". I believe that happens later with the RMI factory.

This is supported if we look back at the DvdFileAccess class and see: "Note that since this should only be used by the DvdDatabase class, the class has been set to have default access".

So the caller is DvdDatabase, a class which we will have many instances of since that's how the author will distinguish multiple clients. I guess my question is if the code is taken from the book "as-is", is it thread safe?

In the sampleproject.db package there is also the DosClient class which serves as a non-gui application test. But only one renter (i.e. one DvdDatabase) is ever instantiated, so it doesn't really assure us that the supplied code is thread-safe?

I think that the original poster has a valid argument saying that with every new client (DvdDatabase) there is a new database object (DvdFileAccess). You think it might be an error or omission in the book? Or am I missing something as well?

Thanks again for clarifying.
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Just to correct myself. getInstance must be static...

Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
You might want to read previous replies of ranchers and Monkhouse on this:

javaranch-009883
javaranch-011154
javaranch-010050
javaranch-010774

Regards,
Alex
[ December 14, 2007: Message edited by: Alex Belisle Turcot ]
Dmitri Christo
Ranch Hand

Joined: Jan 19, 2007
Posts: 81
Thanks Alex, there sure is a lot of previous discussion about the same issue.
 
GeeCON Prague 2014
 
subject: Questions about DvdFileAccess (code from the book)