myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blake Sullivan <blake.sulli...@oracle.com>
Subject Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Date Wed, 30 Jan 2008 21:57:06 GMT
Andy Schwartz wrote:
> Hey Blake -
>
> On Jan 30, 2008 3:57 PM, Blake Sullivan <blake.sullivan@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
>   


Mime
View raw message