> Can anyone figure out what might go wrong in the original version of > the class?
I have no idea how something here can result in a 404.
Do multiple instances create cause the 404?
As far as the locking i wonder if because INSTANCES in a HashMap and not
meant to be used concurrently that this introduces the need to have the
second check. But replacing the HashMap with a ConcurrentHashMap is only
useful when having multiples instances isn't a problem.
On a separate note would the following work as an base implementation
that all our SiteKeyedFactories could use:
static <T> T instanceOf(
final Site site,
final Map<Site,T> instances,
final ReentrantReadWriteLock instancesLock,
final FactoryConstructor<T> constructor){
try {
instancesLock.readLock().lock();
if (!instances.containsKey(site)) {
// It is not possible to upgrade a read lock...
instancesLock.readLock().unlock();
instancesLock.writeLock().lock();
try {
// ...so check the condition again.
if (!instances.containsKey(site)) {
instances.put(site, constructor.construct());
}
} catch (SiteKeyedFactoryInstantiationException e) {
LOG.error(ERR_DOC_BUILDER_CREATION, e);
} finally {
// Downgrade to a read lock.
instancesLock.readLock().lock();
instancesLock.writeLock().unlock();
}
}
return instances.get(site);
} finally {
// Finally release the read lock.
instancesLock.readLock().unlock();
}
}
interface FactoryConstructor<T>{
T construct() throws SiteKeyedFactoryInstantiationException;
}
~mck
--
"Physics is to math what sex is to masturbation." Richard Feynman
| semb.wever.org | sesat.no | sesam.no |
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Kernel-development mailing list [email protected] http://sesat.no/mailman/listinfo/kernel-development
