On Jan 30, 2008 5:01 PM, Andy Schwartz <[EMAIL PROTECTED]> wrote: > Hey All - > > It seems to me that the proposed API is a result of two more > fundamental deficiencies: > > 1. The servlet spec is lame and does not state that ServletContext > implementations must ensure thread-safe access to attributes. > 2. ServletContext implementations are lame and have not switched from > Hashtable to ConcurrentHashMap. > > I think that the solution to #1 is to seek a clarification to the > spec, since it is clearly bogus that the spec is not clear on this > point. Note that the spec has already been updated to be more clear > about concurrent access to HttpSession attributes, see the last couple > of paragraphs of: > > http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/servlet-2.5_MR6.html > > It doesn't seem like that big of a stretch to get a similar > clarification for ServletContext - I suspect that the spec is already > generally interpreted to imply that the ServletContext provides > thread-safe access. Stating this explicitly in the spec does not seem > controversial (well, not to me at least). > > Regarding #2... seems like moving over to ConcurrentHashMap is a > no-brainer for servlet implementations which are still stuck on > Hashtable.
well, the JCP (true for 99% of the specs) is slow; and I am sure, the EG will find some reasons to not make changes... :-) sorry, but is my personal feeling. -M > > If we are able to satisfy our requirements by going down this route, I > would prefer this over adding a somewhat-redundant API to Trinidad > (ie. would prefer fixing the underlying problems so that we can use > the Application map directly rather than adding a new parallel API.) > > Andy > > > On Jan 28, 2008 7:56 PM, Gabrielle Crawford > <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > In case anyone filtered away the [jira] message..... > > > > I'd like to add the method described below to the requestContext. > > > > Comments? Objections? > > > > Thanks, > > > > Gab > > > > -------- Original Message -------- > > > > add method to get an application scoped concurrentMap to RequestContext > > ----------------------------------------------------------------------- > > > > Key: TRINIDAD-926 > > URL: https://issues.apache.org/jira/browse/TRINIDAD-926 > > Project: MyFaces Trinidad > > Issue Type: Improvement > > Affects Versions: 1.2.5-core, 1.0.5-core > > Reporter: Gabrielle Crawford > > Assignee: Gabrielle Crawford > > Priority: Minor > > > > > > This started with Trin Issue 891 > > https://issues.apache.org/jira/browse/TRINIDAD-891 > > > > To avoid the locking in the class loader we'd like to store a map of > > name->class per app. However the external context app map calls through to > > the ServletContext. The Servlet specification doesn't specify whether the > > ServletContext performs any locking on the ServletContext attributes and > > the ServletContext doesn't expose the necessary methods for efficient > > concurrent access (essentially the operations exposed on ConcurrentMap) > > necessary to work efficiently in many cases even if the ServletContext > > didn't need to perform locking on reads. The result is that the > > ExternalContext's ApplicationMap can't implement ConcurrentMap. > > > > We'd like to add a method to the RequestContext to get an application > > scoped concurrent map. This would not call through to the servlet context. > > The api proposed is this: > > > > > > /** > > * Gets a per application concurrent map. There is no synchronization > > * with ServletContext attributes. > > */ > > public abstract ConcurrentMap<String, Object> > > getApplicationScopedConcurrentMap(); > > > > > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
