This factory has two operating modes. By default it ensures, that every thread uses its own component at any time. This mode ( {@link #ENSURE_THREAD_LOCALITY}) makes internal usage of a {@link ThreadLocalized}. If the application architecture ensures, that the thread that creates the component is always also the thread that is th only user, you can set the mode {@link #THREAD_ENSURES_LOCALITY}. In this mode the factory uses a simple {@link Cached} that uses a {@link ThreadLocalReference} to cache the component.
See the use cases for the subtile difference:
THREAD_ENSURES_LOCALITY is applicable, if the pico container is requested for a thread local addComponent from the working thread e.g. in a web application for a request. In this environment it is ensured, that the request is processed from the same thread and the thread local component is reused, if a previous request was handled in the same thread. Note that thi scenario fails badly, if the thread local component is created because of another cached component indirectly by a dependecy. In this case the cached component already have an instance of the thread local component, that may have been created in another thread, since only the component adapter for the thread local component can ensure a unique component for each thread.
ENSURES_THREAD_LOCALITY solves this problem. In this case the returned component is just a proxy for the thread local component and this proxy ensures, that a new component is created for each thread. Even if another cached component has an indirect dependency on the thread local component, the proxy ensures unique instances. This is vital for a multithreaded application that uses EJBs.
| |