How to avoid reads before initialization of all the three maps are done using RentrantLock and return updated set of maps after update is done?

Question 1

You should continue your restructuring along the line you're going with the introduction of Mappings. You don't need to manage the three references individually (this is where it gets complex). Instead, manage one reference.

class ClientData {
  // This is immutable after creation (like your OP)
  class Mappings { /* definition from your original post */ }

  // this should be volatile;
  private static volatile Mappings instance;

  // the read path proceeds without acquiring any lock at all.  Hard to 
  // get faster than a volatile read.  Note the double-checked locking pattern
  // works JDK 6 or greater when using volatile references (above)
  public static Mappings getMappings() {
    Mappings result = instance;
    if(result == null) {
       synchronized(ClientData.class) {
          result = instance;
          // recall while() is required to handle spurious wakeup
          while(result == null) {
             ClientData.class.wait();
             result = instance;
          }
       }
    }
  }

  public static setMappings(Map one, Map two, Map three) {
    synchronized(ClientData.class) {
      instance = new Mappings(one,two,three);
      ClientData.class.notifyAll()
    }
  }
}

I think this has the following benefits:

No locks are required on the read path. This is a side effect of the immutability of the Mappings class. Volatile read is really fast.
Callers that enter getMappings() before it simply wait for it to be set.
No third-party objects semantics to worry about

It's somewhat unfortunate (IMHO) that java doesn't have a good "Waitable Reference" built in. But one can't ask for everything! Third party libraries have some support -- Guava's Suppliers.memoize() is a good place to start.

Good luck with your project.

Question 2

You are right that you need to remove the if (allset) block. Otherwise you won't be able to update.

So, it looks like you have to solve the following problem that could occur:

You call ClientData.getPrimaryMapping()
A wild update appears
You call ClientData.getSecondaryMapping() - now you have mismatching data

Instead of calling all three mapping methods after each other with the possibility of updates in between, I would create a single method to get all maps at once. The method should return a list (or an array or some other kind of container) of your maps. By moving the lock to this method, you can assure that you there won't be any updates while you get your maps.

Something like this for example:

// create a new list on each update
private static List<Map<String, Map<Integer, String>>> mappings;

public static final List<Map<String, Map<Integer, String>>> getAllMappings() {
    lock.lock();
    try {
        while (!allset) {
            allsetnow.await();
        }
        return mappings;
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt(); // reset interruptedd state.
        throw new IllegalStateException(e);
    } finally {
        lock.unlock();
    }

}

I guess it could also be faster because of less method calls and less try catch blocks but if you are really concerned about performance you should measure what performs best.

Question 3

If you have a code block like this

String data1=ClientData.getPrimaryMapping().get(some_value1).get(some_value2);
String data2=ClientData.getSecondaryMapping().get(some_value1).get(some_value3);
String data3=ClientData.getTertiaryMapping().get(some_value1).get(some_value4);

there is nothing you can do within the getMapping method to fix the possible race. There can always be an update between these three lines yielding to inconsistent values for data1, data2, and data3 regardless of how well you sync within the called methods (once you allow updates).

The only way to fix this is to move the sync logic into the caller. In the example code above, all three statements must be placed within the same guarded block. The good news is that this will help your performance as, if you do it properly, you don’t need a lock within the called methods then. So instead of locking and unlocking three times you are doing it only once for the entire block.

For your use case of having tons of reads and only occasional updates, using a ReadWriteLock allowing concurrent reads is a natural choice.

Question 4

Sounds like a Job for a ReadWriteLock.

Any method or process that will cause the three maps to become inconsistent with one another should lock the write lock before it starts, and unlock the write lock after it is finished:

java.util.concurrent.locks.ReaderWriterLock readerWriterLock = ...;

readerWriterLock.writeLock().lock()
try {
    ...update maps...
} finally {
    readerWriterLock.writeLock().unlock()
}

It will be a little more complicated if more than one thread is involved, but the principle remains the same: Keep the write lock locked when you don't want readers to access the maps.

Any method that needs to use the data in the maps should lock the read lock. That looks just the same as in my example above, but substitute "readLock()" for "writeLock()".

Reads block until all three maps have been set for the first time.

Easy! Just make sure that the writeLock is locked before you start any thread that can read the maps, and make sure to unlock it after the maps have been set to their initial consistent state.