Hi,
Am Freitag, den 15.02.2008, 16:31 -0800 schrieb Tobias Bocanegra:
> -1 using thread local is very dangerous and can cause memory leaks
Agreed with respect to "danger", but we do not expose the ThreadLocal
but keep it internal as an implementation detail and depend on observing
the lifecycle requirement: any ResourceResolver obtained must be
released when not used any more.
>
> i strongly recommend to reconsider this approach. whenever i
> encountered the problem that i need a resource resolver but did't had
> the request handy - it was a flaw in my architecture of my classes.
I can assure you that I do not propose the use of ThreadLocals
light-heartedly, exactly because I am aware of its dangers. But weighing
the advantages and disadvantages against each other here, I come to the
conclusion, that it is worth it.
Regards
Felix
>
> regards, toby
>
> On 2/14/08, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > Currently we provide instances of the ResourceResolver interface through
> > the SlingHttpServletRequest.getResourceResolver() method. In addition we
> > have a JcrResourceResolverFactory interface in the jcr/resource module,
> > which creates ResourceResolver instances.
> >
> > There may be cases, where we need a ResourceResolver instance but do not
> > have the SlingHttpServletRequest object at hand and do not want to lock
> > into the jcr/resource module and create new JCR sessions and
> > ResourceResolver instances just to get at resources.
> >
> > So I propose we define a new ResourceResolverProvider interface in the
> > Sling API:
> >
> > public interface ResourceResolverProvider {
> >
> > /**
> > * Returns a ResourceResolver for the current execution context of
> > the
> > * caller or null if no ResourceResolver intance is currently
> > available.
> > */
> > ResourceResolver getResourceResolver();
> >
> > }
> >
> > This interface would be extended by the current
> > JcrResourceResolverFactory interface in the jcr/resource module. The
> > JcrResourceResolverFactoryImpl implementation implements the
> > getResourceResolver() method using ThreadLocal variables as follows:
> >
> > JcrResourceResolverFactoryImpl implements JcrResourceResolverFactory {
> >
> > private ThreadLocal<ResourceResolver> resolver;
> >
> > ResourceResolver getResourceResolver() {
> > return resolver.get();
> > }
> >
> > }
> >
> > The getResourceResolver(Session) method is redefined to return a
> > resource resolver for the given session and to store it in the
> > ThreadLocal if the ThreadLocal is not set yet. If the ThreadLocal is set
> > and the session of the stored ResourceResolver and the session parameter
> > are the same, the ThreadLocal is returned.
> >
> > To be able to cleanup the ThreadLocals a new release(ResourceResolver)
> > is defined, which is required to be called for all ResourceResolver
> > instances retrieved through getResourceResolver(Session).
> >
> > This way, the Sling Main servlet is able to create the ResourceResolver
> > at the start of the request and remove it at the end. Any clients
> > calling ResourceResolverProvider.getResourceResolver() during request
> > processing will get the current request's ResourceResolver.
> >
> > WDYT ?
> >
> > Regards
> > Felix
> >
> >
>
>
