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/02/01 04:18:35 UTC
Re: [Trinidad] add method to get an application scoped concurrentMap
to RequestContext (TRINIDAD-926)
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,
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
> >>
> >
>