Forums Register Login

Facade pattern and thread safety during delegation object creation

+Pie Number of slices to send: Send
Hi,

I am using the facade pattern following Andrew Monkhouse's book and am
planning to use RMI for the network connection (project is UrlyBird).
So, I will have several Data (the facade object) classes, but only one
delegatee for the database operations, like this:


This delegatee itself uses some static helper objects, which get their
initial (and, for databaseDescriptor, also final) state during the
delegatee's initialization:


For example, the databaseDescriptor parses and keeps the header
information, and the positionProvider gets a list of deleted positions
at startup.

As these helper classes have state, I think that the code as-is is not
thread-safe regarding creation of the fileDatabase delegatee. I am
wondering how to make it thread-safe:

1) Evidently I cannot make this field immutable according to the
definition "is transitively reachable from a final field, has not
changed since the final field was set, and a reference to the object
containing the final field did not escape the constructor"
(http://jeremymanson.blogspot.com/2008_04_01_archive.html), as I cannot
make it final and during all the actions that happen during the
initialization of fileDatabase there will surely escape some reference...

2) Making the field "private static Database database" volatile, would
this be sufficient, as all threads should get the same results anyway?
Or could still corruption result during the following actions? (Make all
static fields volatile?)

3) Monitor the initialization process like in Effective Java 2, item 74,
with a State enum and setting the state to initialized after all actions
are finished only?

4) Very ugly I suppose: make the Data constructor itself synchronized?

5) Double-checked locking in the constructor?

BTW I'm not sure about the example project in the Monkhouse book - it
does not do any synchronization at that point either, but the
dVDFileAccess class seems to have state too (the recordNumbers map)?

I'd be very thankful for your help & responses with this,
Sigrid
+Pie Number of slices to send: Send
+Pie Number of slices to send: Send
Hi Karl,

many thanks for your reply. In fact, as I read in Effective Java 2 (Item 71), the double-checked locking works now, due to a change in the Java Memory Model. But the field has to be volatile for that (I forgot to mention this in my post).
I would be very curious to know how other people handled this problem? In fact I am still not even sure I have to synchronize here, as AFAIS there is no equivalent synchronization in the DVDDatabase sample project - perhaps I'm overly cautious? (Mr Monkhouse perhaps if you read this... could you give me a hint ?)

Thanks for any comments...
Sigrid
+Pie Number of slices to send: Send
 

Originally posted by Karl Fenton:
at least avoid DCL => http://www.javaworld.com/jw-02-2001/jw-0209-double.html



This article was posted in 2001. I wonder if this issue has not been solved yet...
I'm using DLC but now I don't know if I will keep it...

Thanks for the warning!

Baldo.
+Pie Number of slices to send: Send
yes it has been fixed - see

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
(you have to scroll down a bit)

but the field has to be volatile for that
Live ordinary life in an extraordinary way. Details embedded in this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1262 times.
Similar Threads
Double checked locking
Unsafe publication of objects.
is this class thread-safe ?
threadsafety of a singleton
Singleton initialization (exceptions, thread-safety)
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 10:49:46.