A way to make double-checked locking work?

Question

First a little background.
I am writing an application that will run in an websphere/db2 environment. This application needs to provide a lot of referential data to the UI to properly populate certain fields (on the order of several dozen reference data requests per page request with about 3-400 concurrent users). To prevent 20 sql statements for a single user clicking a single link, I implemented a dynamic caching scheme with double-checked locking, not realizing the potential danger.
After reading an article I found on the pitfalls of double-checked locking (http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-toolbox.html), I still would like to prevent synchronizing on every cache request. I think I've found a solution that transfers the weight to the write operations, as those would be much less frequent and can therefore take the bigger load. I would like to see if anyone can find a hole in this.
public class DCLTest {
  private Resource rec = null;
  boolean initializing = false;
  public Resource getResource() {
    Resource temp = null;
    if (rec == null) {
      synchronized (this) {
        // initializing is now synchronized w/ main memory
        if (initializing)
          wait();
        if (rec == null) {
          // resource has lots of non-trivial datamembers that get initialized in the constructor
          temp = new Resource();
          initializing = true;
      // If initializing is true, we know it's set by this thread,
      // but still check that temp is valid
      if (initializing && (temp != null)) {
        synchronized (this) {
          rec = temp;
          initializing = false;
          notifyAll();
}The first synchronize block establishes the first set of boundaries. When it completes, the initializing flag is raised and any other thread waiting to enter that block will see the flag and wait. Also, when the block is executed, all of the resource object's internal fields get written to the main memory, but the "global" pointer will still be null. Once we enter the second synchronized block, we update the global pointer and reset the flag. Since both synchronized blocks synchronize on "this", calling notifyAll won't resume execution of the threads that are waiting until they re-acquire the lock on this, or in other terms, until the second synchronized block completes. By that point the initializing flag will be false, the rec field will be not null and rec's data members will be in sync between all threads trying to access it.
This all depends on the assumption that the optimizer won't combine the two synchronized blocks. If that's the case, the two synchronized blocks assure that the reference to rec is written (and made visible to main memory) after the actual contents of rec are in main memory. Therefore, if a reading thread acquires a non-null value in the check outside the synchronized block, it will acquirea proper value. Otherwise, it'll get a null and will enter the synchronized block and all is well.
This logic seems too good to be true (which unfortunately means it probably is), but I can't find the hole. The only justification my gut can give this is the fact that the write operation becomes slower than if both read and write were synchronized, which is acceptable in my case.

Answer 1

a big flaw (but easily solvable) is that there is no
guarentee that changes made to your "initializing"
variable
will ever be seen by other threads. It needs to be
marked volatile.this is not true. the JLS states that all threads are required to load from main memory on the first use of a variable in its lifetime. This would happen the first time a thread checks rec. When that check occurs, it will load from main memory and eihter get a null and enter the sync block, or get a valid reference and continue.
17.3 After a thread is created, it must perform an assign or load action
on a variable before performing a use or store action on that variable.
A second flaw is that you never set rec to anything
other then null.
( a single thread will enter the first synch block and
obtain a reference to temp. It will then NOT enter
the
second synch block as initializing is false. hence
your rec variable will be null)why is initializing false? it's set to true within the first block.
temp = new Resource();          
initializing = true;
Third.
rec is null. The first thread enters the first synch
block and stops before changing the initializing
valriable. A
second thread then tries to enter the synch block. It
cannot get the monitor and therefore yeilds. The first
thread then continues inside the synch block. It just
leaves the first synch block before being stopped. The
second thread then resumes. It obtains the lock on the
first sych block. initilaizing is false so it skips
the
wait() statment. Rec is still null so the second
thread creates a new one. Now you have two threads
each has
a local reference to different Resource's. Which one
gets used? (actually at the moment niether would
get used cos of the previous problem)the whole idea of initializing is that it never gets written outside of a synchronized block. if a thread cuts in just as the first thread left the first sync block, initializing is set to true, so it will simply wait. This is to make sure that no one does anything while the thread that's initializing is in between the two sync blocks.
i think you overlooked where initializing is set to true in the first block