Re: [picocontainer-dev] SynchronizedComponentAdapter ???
Paul Hammant <[email protected]>
| Newsgroups | gmane.comp.java.picocontainer.devel |
|---|---|
| Message-ID | <[email protected]> |
'Monster' is relative ;-)
One new member var 'lock' (that's final), and ....
public Object getComponentInstance(PicoContainer container)
throws PicoInitializationException,
PicoIntrospectionException, AssignabilityRegistrationException,
NotConcreteRegistrationException {
if (instanceReference.get() == null) {
Object tmp = super.getComponentInstance(container);
synchronized (lock) {
if (instanceReference.get() == null) {
instanceReference.set(tmp);
}
}
}
return instanceReference.get();
}
instead of ....
public Object getComponentInstance(PicoContainer container)
throws PicoInitializationException,
PicoIntrospectionException, AssignabilityRegistrationException,
NotConcreteRegistrationException {
Object instance = instanceReference.get();
if (instance == null) {
instance = super.getComponentInstance(container);
instanceReference.set(instance);
}
return instance;
}
It gets rid of two classes, and is the minimally contentious way in
that synchronized could be done for CCA.
Thoughts?
-ph
On May 21, 2007, at 2:28 AM, Jörg Schaible wrote:
> Paul Hammant wrote on Monday, May 21, 2007 8:37 AM:
>
>> Does anyone use this ?
>>
>> Maybe functionality could go into CachingCompAdapter as default
>> behavior.
>>
>> Not synchronize on the whole method, just on the setting of
>> 'instance' ??
>
> No, it's again necessary as separate step in the chain. Don't try
> to turn the CachingCA in the "one-fits-all" monster.
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email