Java Singleton @Lock(LockType.WRITE)

Nisem najbolj domač v Javi, me pa zanima kako rešiti sledečo situacijo:

1. Imaš Singleton class, po EJB specifikaciji kontejner upravlja dostope iz več threadov, po defaultu so metode LockType.WRITE, razen če je anotirano drugače

2. imaš več metod, ki berejo podatke iz classa (recimo da metoda vrne nek private Map). Anotiraš LockType.READ zato ker je izvedba kratka in ker hočeš da več threadov bere hkrati iz map ki jih vračaš. Mape se tukaj ne bodo spreminjale.

3. imaš metodo reload(), ki osveži podatke iz baze in jih naloži v mapo. Metoda traja dalj časa zato ker mora prebrat vse podatke iz baze...metoda je @Schedule recimo na vsako uro.

Kako zagotovit čim večji concurrency?
Če reload() metodo anotiraš LockType.WRITE, potem je dostop do ostalih metod zaklenjen dokler se refresh ne dokonča. Recimo da ni pomembno, če kakšna read metoda dobi še staro mapo, refresh() metodo pa lahko narediš da najprej polni podatke v lokalno temp mapo, ki jo nakoncu izvajanja zamenjaš z class global mapo, ki jo vračajo read funkcije.

Problem je ta zadnji korak - za zamenjavo map, ko si že prebral podatke iz baze in da zamenjaš globalno mapo, ki jo vračajo read metode, bi načeloma moral upgradati LockType.WRITE. Dokler si podatke polnil v temp mapo, ni problem če se izvajajo read metode, na koncu pa za čas zamenjave mape rabiš exclusive lock.

Kako to narediti by-the-book? Poseben synchronized block? It v celoti na ConcurrencyManagementType.BEAN? Ker če interno znotraj classa kličeš drugo metodo, se lock ne upošteva (ker si že v containerju), če kličeš getBusinessObject() dobiš IllegalLoopbackException, ker si v READ locku:

If a loopback call occurs on a Singleton that holds a Read lock on the same thread ( but does not also hold a Write lock on the same thread ) :
• If the target of the loopback call is a Write method, a javax.ejb.IllegalLoopbackException must be thrown to the caller.

Kreirat timer ki bo po prebranih podatkih čez 1 sekundo klical drugo LockType.WRITE metodo in zamenjal staro mapo z novo? Sigurno obstaja boljši način...

reload() kliče samo @Schedule.
Map je več, read metode pa niso čisto vedno atomarne, ker včasih delajo kak containsKey(). Najbolj čisto se mi zdi da bi za tisti trenutek zamenjave map imel exclusive lock.

OK, lahko bi tudi poenostavil read() metode da ima samo 1 atomic operacijo, ampak to bi pa že potem spet spreminjal arhitekturo.

Ja, tako bo najbrž najlažje da se ne ukvarjam s container lockingom...
Hvala.

Ce imas vec kot eno mapo si naredi en class ki vsebuje vse mape ki jih loadas, tako da potem na koncu reloada zamenjas instanco tega classa, tako poskrbis da so vse mape zamenjane hkrati.