Forums Register Login

Questions about DvdFileAccess (code from the book)

+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
Just to correct myself. getInstance must be static...

+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
Thanks Alex, there sure is a lot of previous discussion about the same issue.
Yeah, but does being a ninja come with a dental plan? And what about this tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1359 times.
Similar Threads
B & S read method of interface
Errors in "SCJD Exam with J2SE 5" book
B & S read method
SCJD Exam with J2SE book : DvdFileAccess Constructor
can cache be loaded throught private constructor
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 06:56:07.