Andy Schwartz 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.
This one I'm not worried about, because I doubt that any Servlet
container doesn't do this
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.
This is more of an issue, however the other problem is that the
ServletContext and Session still don't expose the atomic operations of
ConcurrentMap. Neither do they document what object they do lock on.
Without either of these pieces, it is impossible to perform compound
operations on these Objects atomically safely. We could guess that the
implementations are using the Objects themselves as the monitors, but
not only is that not documented, but doing so would not work if the
implementations used ConcurrentHashMap, which uses lock striping internally.
-- Blake Sullivan
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.
