On 09/18/11 05:21, Mark Thomas wrote:
> On 01/09/2011 19:21, Kin-man Chung wrote:
>
>> I've been thinking about adding some API's for cache control in EL. My
>> original idea was to add two methods
>>
>> Mark m = mark(); // place a marker
>> release(m); // release cache in this thread since m was marked.
>>
>> There probably should be a restriction that marks and releases be
>> properly nested, so that caches can be allocated and released like a stack.
>>
>> The above scheme would probably work well for a single threaded
>> execution, but not in a mutli-threaded program. Since marks and
>> releases from other threads can come randomly, I don't know how to
>> implement these methods properly and efficiently, and I suspect that
>> such API is not useful at all.
>>
>> One can argue that with this API, caching should be implemented on a per
>> thread basis, with no sharing between threads. I suspect there may be
>> very little common expressions between threads anyway. However, this
>> would rely too much on user interactions, and can lead to memory
>> leakage if an user forgets to call release at the right time.
>>
>> In any case, cache control is an optional part of the spec, since it
>> cannot be probably tested. If any of you have other ideas, please
>> share, otherwise I'll move it down the priority list for now, and come
>> back to it later if we have time.
>>
> The proposal above doesn't discuss what should be cached.
>
See below.
> I would expect to see a large degree of commonality of EL usage between
> threads in web applications.
>
I have to agree with you on this. :-) What about the modified
assumption: there is little cache sharing between two web applications.
What I had in mind is something like this. When an application is
started, an EL cache is created, and it will be used for all EL
evaluations for this application, and when applications is unloaded, the
cache is removed. I think this model works well with web applications.
What I am having problem with is I don't know how to identify
expressions from an application.
> The Tomcat EL implementation currently has two caches that are
> controlled by system properties. One cache is for BeanProperties objects
> used by the BeanELResolver, the other is for parsed expressions. The
> caches are currently global.
>
>
We have something similar in GlassFish. The problem with global caches
is that they are potential sources for memory leaks. That's why I want
an API to let the application tell EL when entries in the EL cache can
be removed.
> The questions that come to mind are:
>
> 1. What exactly is it that we want to cache? Using the Tomcat
> implementation as a starting point, is this caching a) completely the
> wrong things, b) exactly what we want, c) heading in the right direction
> but could stand some improvement?
>
I think what to cache sounds like implementation details and is outside
the domain of the spec. I think the implementation should be free to
cache whatever it thinks is beneficial. What we need in the spec, is to
introduce API's to help to manage the cache better.
> 2. What should the scope of the cache be? Global, per calling class
> loader, per thread, something else?
>
>
By now you probably know that my answer is the application scope, i.e.
per class loader. I thinks managing cache well in an application would
give us the most benefit. WDYT?
Like I said, this is going to be an optional part of the spec, so we
don't need to have one unless it is really useful. Unfortunately we
won't know for sure until it is implemented and measured.
Kin-man
> Mark
>