You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Gabrielle Crawford <ga...@oracle.com> on 2008/01/29 01:56:46 UTC
[Trinidad] add method to get an application scoped concurrentMap
to RequestContext (TRINIDAD-926)
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.
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Posted by Martin Marinschek <ma...@gmail.com>.
Excellent! we should definitely get this into the impl as well ;)
regards,
Martin
On Jan 29, 2008 8:08 PM, Gabrielle Crawford <ga...@oracle.com>
wrote:
> Oops, and _getClassLoader
>
> private ClassLoader _getClassLoader()
> {
> return Thread.currentThread().getContextClassLoader();
> }
>
> Gabrielle Crawford wrote:
> > Here's the implementation I have so far in
> > org.apache.myfaces.trinidadinternal.context.RequestContextImpl
> >
> > @Override
> > public ConcurrentMap<String, Object>
> getApplicationScopedConcurrentMap()
> > {
> > ClassLoader cl = _getClassLoader();
> >
> > ConcurrentMap<String, Object> classMap = _applicationMaps.get(cl);
> >
> > if (classMap == null)
> > {
> > ConcurrentMap<String, Object> newClassMap = new
> > ConcurrentHashMap<String, Object>();
> > ConcurrentMap<String, Object> oldClassMap =
> > _applicationMaps.putIfAbsent(cl, newClassMap);
> >
> > classMap = ((oldClassMap != null)? oldClassMap : newClassMap);
> >
> > assert(classMap != null);
> > }
> >
> > return classMap;
> > }
> >
> >
> > @SuppressWarnings({"CollectionWithoutInitialCapacity"})
> > private static final ConcurrentMap<ClassLoader,
> > ConcurrentMap<String, Object>> _applicationMaps =
> > new ConcurrentHashMap<ClassLoader, ConcurrentMap<String,
> > Object>>();
> >
> > Martin Marinschek wrote:
> >> where will this map be stored?
> >>
> >> regards,
> >>
> >> Martin
> >>
> >> On Jan 29, 2008 6:38 AM, Matthias Wessendorf <matzew@apache.org
> >> <ma...@apache.org>> wrote:
> >>
> >> +1
> >>
> >> On Jan 29, 2008 2:48 AM, Blake Sullivan
> >> <blake.sullivan@oracle.com <ma...@oracle.com>>
> wrote:
> >> > I'm, of course, in favor.
> >> >
> >> > -- Blake Sullivan
> >> >
> >> >
> >> > Gabrielle Crawford 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();
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> further stuff:
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> mail: matzew-at-apache-dot-org
> >>
> >>
> >>
> >>
> >> --
> >>
> >> http://www.irian.at
> >>
> >> Your JSF powerhouse -
> >> JSF Consulting, Development and
> >> Courses in English and German
> >>
> >> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [Trinidad] add method to get an application scoped concurrentMap
to RequestContext (TRINIDAD-926)
Posted by Gabrielle Crawford <ga...@oracle.com>.
Oops, and _getClassLoader
private ClassLoader _getClassLoader()
{
return Thread.currentThread().getContextClassLoader();
}
Gabrielle Crawford wrote:
> Here's the implementation I have so far in
> org.apache.myfaces.trinidadinternal.context.RequestContextImpl
>
> @Override
> public ConcurrentMap<String, Object> getApplicationScopedConcurrentMap()
> {
> ClassLoader cl = _getClassLoader();
>
> ConcurrentMap<String, Object> classMap = _applicationMaps.get(cl);
>
> if (classMap == null)
> {
> ConcurrentMap<String, Object> newClassMap = new
> ConcurrentHashMap<String, Object>();
> ConcurrentMap<String, Object> oldClassMap =
> _applicationMaps.putIfAbsent(cl, newClassMap);
>
> classMap = ((oldClassMap != null)? oldClassMap : newClassMap);
>
> assert(classMap != null);
> }
>
> return classMap;
> }
>
>
> @SuppressWarnings({"CollectionWithoutInitialCapacity"})
> private static final ConcurrentMap<ClassLoader,
> ConcurrentMap<String, Object>> _applicationMaps =
> new ConcurrentHashMap<ClassLoader, ConcurrentMap<String,
> Object>>();
>
> Martin Marinschek wrote:
>> where will this map be stored?
>>
>> regards,
>>
>> Martin
>>
>> On Jan 29, 2008 6:38 AM, Matthias Wessendorf <matzew@apache.org
>> <ma...@apache.org>> wrote:
>>
>> +1
>>
>> On Jan 29, 2008 2:48 AM, Blake Sullivan
>> <blake.sullivan@oracle.com <ma...@oracle.com>> wrote:
>> > I'm, of course, in favor.
>> >
>> > -- Blake Sullivan
>> >
>> >
>> > Gabrielle Crawford 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();
>> > >
>> > >
>> >
>> >
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> further stuff:
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> mail: matzew-at-apache-dot-org
>>
>>
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
Re: [Trinidad] add method to get an application scoped concurrentMap
to RequestContext (TRINIDAD-926)
Posted by Gabrielle Crawford <ga...@oracle.com>.
Here's the implementation I have so far in
org.apache.myfaces.trinidadinternal.context.RequestContextImpl
@Override
public ConcurrentMap<String, Object> getApplicationScopedConcurrentMap()
{
ClassLoader cl = _getClassLoader();
ConcurrentMap<String, Object> classMap = _applicationMaps.get(cl);
if (classMap == null)
{
ConcurrentMap<String, Object> newClassMap = new
ConcurrentHashMap<String, Object>();
ConcurrentMap<String, Object> oldClassMap =
_applicationMaps.putIfAbsent(cl, newClassMap);
classMap = ((oldClassMap != null)? oldClassMap : newClassMap);
assert(classMap != null);
}
return classMap;
}
@SuppressWarnings({"CollectionWithoutInitialCapacity"})
private static final ConcurrentMap<ClassLoader, ConcurrentMap<String,
Object>> _applicationMaps =
new ConcurrentHashMap<ClassLoader, ConcurrentMap<String, Object>>();
Martin Marinschek wrote:
> where will this map be stored?
>
> regards,
>
> Martin
>
> On Jan 29, 2008 6:38 AM, Matthias Wessendorf <matzew@apache.org
> <ma...@apache.org>> wrote:
>
> +1
>
> On Jan 29, 2008 2:48 AM, Blake Sullivan <blake.sullivan@oracle.com
> <ma...@oracle.com>> wrote:
> > I'm, of course, in favor.
> >
> > -- Blake Sullivan
> >
> >
> > Gabrielle Crawford 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();
> > >
> > >
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Posted by Martin Marinschek <ma...@gmail.com>.
where will this map be stored?
regards,
Martin
On Jan 29, 2008 6:38 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> +1
>
> On Jan 29, 2008 2:48 AM, Blake Sullivan <bl...@oracle.com> wrote:
> > I'm, of course, in favor.
> >
> > -- Blake Sullivan
> >
> >
> > Gabrielle Crawford 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();
> > >
> > >
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Posted by Matthias Wessendorf <ma...@apache.org>.
+1
On Jan 29, 2008 2:48 AM, Blake Sullivan <bl...@oracle.com> wrote:
> I'm, of course, in favor.
>
> -- Blake Sullivan
>
>
> Gabrielle Crawford 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();
> >
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] add method to get an application scoped concurrentMap
to RequestContext (TRINIDAD-926)
Posted by Blake Sullivan <bl...@oracle.com>.
I'm, of course, in favor.
-- Blake Sullivan
Gabrielle Crawford 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();
>
>
Re: [Trinidad] add method to get an application scoped concurrentMap
to RequestContext (TRINIDAD-926)
Posted by Gabrielle Crawford <ga...@oracle.com>.
Hi,
Yes, I think I wasn't clear. :-)
Okay, so I think I have a +1 from everyone who commented now....
Thanks,
Gab
Andy Schwartz wrote:
> Hey Gab -
>
> Originally I was concerned that we were adding this API in order to
> work around lock contention issues in ServletContext implementations,
> which I would prefer to see addressed by the ServletContext
> implementations rather than by adding a workaround to Trinidad.
> However, if the deal is that we really want access to
> ConcurrentHashMap's atomic operations (putIfAbsent()), then I am down
> with adding a Trinidad-level solution, so +1.
>
> Andy
>
>
> On Jan 31, 2008 10:18 PM, Gabrielle Crawford
> <ga...@oracle.com> wrote:
>
>> Hi Andy,
>>
>> So let's say I want to store a value on the app map and I want to make
>> sure I don't overwrite an existing value. With the externalContext app
>> map I don't have concurrentMap api's, so I think I have to lock in my
>> code while I check for the value and create if null.
>>
>> If I got back a concurrentMap instead of a map I could check for null,
>> create if null, and call putIfAbsent without locking the app map....
>>
>>
>> Gab
>>
>>
>>
>>
>> Blake Sullivan wrote:
>>
>>> Andy Schwartz wrote:
>>>
>>>> Hey Blake -
>>>>
>>>> On Jan 30, 2008 3:57 PM, Blake Sullivan <bl...@oracle.com> wrote:
>>>>
>>>>
>>>>
>>>>> I believe that we do want to do this, but we can hold off until we have
>>>>> concrete needs unless the synchronization is actually killing our
>>>>> performance on the Servlet Container implementations that we need to run on.
>>>>>
>>>>>
>>>> Sounds good.
>>>>
>>>>
>>>>
>>>>> The issue for the Servlet implementations with moving over is that if code
>>>>> is currently relying on the implementations performing their synchronization
>>>>> for compound operations on the publicly accessible objects, the
>>>>> implementations can't change to ConcurrentHashMap without breaking this
>>>>> code.
>>>>>
>>>>>
>>>> Okay, I am confused... Since the ServletContext's attribute Map is
>>>> not a publicly accessible object (only access is through
>>>> get/setAttribute()), can't the change be made transparently to app
>>>> developers?
>>>>
>>>>
>>> It can, assuming that the developers realized that they were hosed by
>>> the servlet specification and were just out of luck for compound
>>> operations. The possibilities from most likely to the least likely
>>> for what a developer would do in this case are:
>>> 1) Not realize that synchronization is needed at all
>>> 2) Synchronize on the ServletContext, which either
>>> a) Doesn't work and developer never notices race condition
>>> b) Doesn't work, but developer ignores occassional bugs
>>> c) Works because the implementation used the same lock
>>> 3) Realize they are hosed and give up
>>> 4) Realize they are hosed and switch to a performing synchronization
>>> in a single complex object
>>>
>>> If enough developers are successfully using 2c), the Servlet
>>> implementation would be loathe to actually break them even though it
>>> is legal. This is the downside of blowing off seriously thinking
>>> about threading--developers rely on unspecified behavior.
>>>
>>> -- Blake Sullivan
>>>
>>>
>>>> Andy
>>>>
>>>>
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Posted by Andy Schwartz <an...@gmail.com>.
Hey Gab -
Originally I was concerned that we were adding this API in order to
work around lock contention issues in ServletContext implementations,
which I would prefer to see addressed by the ServletContext
implementations rather than by adding a workaround to Trinidad.
However, if the deal is that we really want access to
ConcurrentHashMap's atomic operations (putIfAbsent()), then I am down
with adding a Trinidad-level solution, so +1.
Andy
On Jan 31, 2008 10:18 PM, Gabrielle Crawford
<ga...@oracle.com> wrote:
> Hi Andy,
>
> So let's say I want to store a value on the app map and I want to make
> sure I don't overwrite an existing value. With the externalContext app
> map I don't have concurrentMap api's, so I think I have to lock in my
> code while I check for the value and create if null.
>
> If I got back a concurrentMap instead of a map I could check for null,
> create if null, and call putIfAbsent without locking the app map....
>
>
> Gab
>
>
>
>
> Blake Sullivan wrote:
> > Andy Schwartz wrote:
> >> Hey Blake -
> >>
> >> On Jan 30, 2008 3:57 PM, Blake Sullivan <bl...@oracle.com> wrote:
> >>
> >>
> >>> I believe that we do want to do this, but we can hold off until we have
> >>> concrete needs unless the synchronization is actually killing our
> >>> performance on the Servlet Container implementations that we need to run on.
> >>>
> >>
> >> Sounds good.
> >>
> >>
> >>> The issue for the Servlet implementations with moving over is that if code
> >>> is currently relying on the implementations performing their synchronization
> >>> for compound operations on the publicly accessible objects, the
> >>> implementations can't change to ConcurrentHashMap without breaking this
> >>> code.
> >>>
> >>
> >>
> >> Okay, I am confused... Since the ServletContext's attribute Map is
> >> not a publicly accessible object (only access is through
> >> get/setAttribute()), can't the change be made transparently to app
> >> developers?
> >>
> > It can, assuming that the developers realized that they were hosed by
> > the servlet specification and were just out of luck for compound
> > operations. The possibilities from most likely to the least likely
> > for what a developer would do in this case are:
> > 1) Not realize that synchronization is needed at all
> > 2) Synchronize on the ServletContext, which either
> > a) Doesn't work and developer never notices race condition
> > b) Doesn't work, but developer ignores occassional bugs
> > c) Works because the implementation used the same lock
> > 3) Realize they are hosed and give up
> > 4) Realize they are hosed and switch to a performing synchronization
> > in a single complex object
> >
> > If enough developers are successfully using 2c), the Servlet
> > implementation would be loathe to actually break them even though it
> > is legal. This is the downside of blowing off seriously thinking
> > about threading--developers rely on unspecified behavior.
> >
> > -- Blake Sullivan
> >
> >> Andy
> >>
> >
>
Re: [Trinidad] add method to get an application scoped concurrentMap
to RequestContext (TRINIDAD-926)
Posted by Gabrielle Crawford <ga...@oracle.com>.
Hi Andy,
So let's say I want to store a value on the app map and I want to make
sure I don't overwrite an existing value. With the externalContext app
map I don't have concurrentMap api's, so I think I have to lock in my
code while I check for the value and create if null.
If I got back a concurrentMap instead of a map I could check for null,
create if null, and call putIfAbsent without locking the app map....
Gab
Blake Sullivan wrote:
> Andy Schwartz wrote:
>> Hey Blake -
>>
>> On Jan 30, 2008 3:57 PM, Blake Sullivan <bl...@oracle.com> wrote:
>>
>>
>>> I believe that we do want to do this, but we can hold off until we have
>>> concrete needs unless the synchronization is actually killing our
>>> performance on the Servlet Container implementations that we need to run on.
>>>
>>
>> Sounds good.
>>
>>
>>> The issue for the Servlet implementations with moving over is that if code
>>> is currently relying on the implementations performing their synchronization
>>> for compound operations on the publicly accessible objects, the
>>> implementations can't change to ConcurrentHashMap without breaking this
>>> code.
>>>
>>
>>
>> Okay, I am confused... Since the ServletContext's attribute Map is
>> not a publicly accessible object (only access is through
>> get/setAttribute()), can't the change be made transparently to app
>> developers?
>>
> It can, assuming that the developers realized that they were hosed by
> the servlet specification and were just out of luck for compound
> operations. The possibilities from most likely to the least likely
> for what a developer would do in this case are:
> 1) Not realize that synchronization is needed at all
> 2) Synchronize on the ServletContext, which either
> a) Doesn't work and developer never notices race condition
> b) Doesn't work, but developer ignores occassional bugs
> c) Works because the implementation used the same lock
> 3) Realize they are hosed and give up
> 4) Realize they are hosed and switch to a performing synchronization
> in a single complex object
>
> If enough developers are successfully using 2c), the Servlet
> implementation would be loathe to actually break them even though it
> is legal. This is the downside of blowing off seriously thinking
> about threading--developers rely on unspecified behavior.
>
> -- Blake Sullivan
>
>> Andy
>>
>
Re: [Trinidad] add method to get an application scoped concurrentMap
to RequestContext (TRINIDAD-926)
Posted by Blake Sullivan <bl...@oracle.com>.
Andy Schwartz wrote:
> Hey Blake -
>
> On Jan 30, 2008 3:57 PM, Blake Sullivan <bl...@oracle.com> wrote:
>
>
>> I believe that we do want to do this, but we can hold off until we have
>> concrete needs unless the synchronization is actually killing our
>> performance on the Servlet Container implementations that we need to run on.
>>
>
> Sounds good.
>
>
>> The issue for the Servlet implementations with moving over is that if code
>> is currently relying on the implementations performing their synchronization
>> for compound operations on the publicly accessible objects, the
>> implementations can't change to ConcurrentHashMap without breaking this
>> code.
>>
>
>
> Okay, I am confused... Since the ServletContext's attribute Map is
> not a publicly accessible object (only access is through
> get/setAttribute()), can't the change be made transparently to app
> developers?
>
It can, assuming that the developers realized that they were hosed by
the servlet specification and were just out of luck for compound
operations. The possibilities from most likely to the least likely for
what a developer would do in this case are:
1) Not realize that synchronization is needed at all
2) Synchronize on the ServletContext, which either
a) Doesn't work and developer never notices race condition
b) Doesn't work, but developer ignores occassional bugs
c) Works because the implementation used the same lock
3) Realize they are hosed and give up
4) Realize they are hosed and switch to a performing synchronization in
a single complex object
If enough developers are successfully using 2c), the Servlet
implementation would be loathe to actually break them even though it is
legal. This is the downside of blowing off seriously thinking about
threading--developers rely on unspecified behavior.
-- Blake Sullivan
> Andy
>
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Posted by Andy Schwartz <an...@gmail.com>.
Hey Blake -
On Jan 30, 2008 3:57 PM, Blake Sullivan <bl...@oracle.com> wrote:
> I believe that we do want to do this, but we can hold off until we have
> concrete needs unless the synchronization is actually killing our
> performance on the Servlet Container implementations that we need to run on.
Sounds good.
> The issue for the Servlet implementations with moving over is that if code
> is currently relying on the implementations performing their synchronization
> for compound operations on the publicly accessible objects, the
> implementations can't change to ConcurrentHashMap without breaking this
> code.
Okay, I am confused... Since the ServletContext's attribute Map is
not a publicly accessible object (only access is through
get/setAttribute()), can't the change be made transparently to app
developers?
Andy
Re: [Trinidad] add method to get an application scoped concurrentMap
to RequestContext (TRINIDAD-926)
Posted by Blake Sullivan <bl...@oracle.com>.
Andy Schwartz wrote:
> Hey Blake -
>
> On Jan 30, 2008 11:52 AM, Blake Sullivan <bl...@oracle.com> wrote:
>
>
>> 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.
>>
>
> Sure, makes sense. If we have requirements for direct access to the
> ConcurrentHashMap atomic APIs, then I agree we'll need our own
> ConcurrentHashMap (Servlet API isn't going to provide this for us).
>
I believe that we do want to do this, but we can hold off until we have
concrete needs unless the synchronization is actually killing our
performance on the Servlet Container implementations that we need to run on.
> If the main concern is avoiding the annoying lock contention that
> results from use of Hashtable in ServletContext implementations, I
> would prefer to skip adding a new API and instead focus on getting
> ServletContext implementations to move over to ConcurrentHashMap.
>
The issue for the Servlet implementations with moving over is that if
code is currently relying on the implementations performing their
synchronization for compound operations on the publicly accessible
objects, the implementations can't change to ConcurrentHashMap without
breaking this code.
-- Blake Sullivan
> Andy
>
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Posted by Andy Schwartz <an...@gmail.com>.
Hey Blake -
On Jan 30, 2008 11:52 AM, Blake Sullivan <bl...@oracle.com> wrote:
> 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.
Sure, makes sense. If we have requirements for direct access to the
ConcurrentHashMap atomic APIs, then I agree we'll need our own
ConcurrentHashMap (Servlet API isn't going to provide this for us).
If the main concern is avoiding the annoying lock contention that
results from use of Hashtable in ServletContext implementations, I
would prefer to skip adding a new API and instead focus on getting
ServletContext implementations to move over to ConcurrentHashMap.
Andy
Re: [Trinidad] add method to get an application scoped concurrentMap
to RequestContext (TRINIDAD-926)
Posted by Blake Sullivan <bl...@oracle.com>.
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
> <ga...@oracle.com> 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.
>>
>>
>>
>>
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Posted by Matthias Wessendorf <ma...@apache.org>.
Hey Andy,
On Jan 30, 2008 5:20 PM, Andy Schwartz <an...@gmail.com> wrote:
> Hi Matthias -
>
> > 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...
> > :-)
>
> In that case here is an alternate approach:
>
> 1. Keep using the application map.
> 2. Log bugs against any servlet implementations that are stuck in
> Hashtable-land (eg. Glassfish) as this implementation poses
> scalability problems and there is an obvious and trivial solution
> (ConcurrentHashMap).
let me check tomcat / jetty ;-)
> 3. Not worry about the possibility of servlet implementations that are
> providing totally unsynchronized access to ServletContext properties.
>
> The reason why I am not worried about #3 is because I don't think these exist.
>
> We can also do:
>
> 4. Follow up with the JCP for clarification.
yeah.
-Matthias
>
> Andy
>
>
>
>
> >
> > sorry, but is my personal feeling.
> >
> > -M
> >
> >
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Posted by Andy Schwartz <an...@gmail.com>.
Hi Matthias -
> 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...
> :-)
In that case here is an alternate approach:
1. Keep using the application map.
2. Log bugs against any servlet implementations that are stuck in
Hashtable-land (eg. Glassfish) as this implementation poses
scalability problems and there is an obvious and trivial solution
(ConcurrentHashMap).
3. Not worry about the possibility of servlet implementations that are
providing totally unsynchronized access to ServletContext properties.
The reason why I am not worried about #3 is because I don't think these exist.
We can also do:
4. Follow up with the JCP for clarification.
Andy
>
> sorry, but is my personal feeling.
>
> -M
>
>
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Posted by Matthias Wessendorf <ma...@apache.org>.
On Jan 30, 2008 5:01 PM, Andy Schwartz <an...@gmail.com> 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
> <ga...@oracle.com> 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
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Posted by Andy Schwartz <an...@gmail.com>.
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.
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
<ga...@oracle.com> 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.
>
>
>