Andy Schwartz wrote:
Hey Blake -
On Jan 30, 2008 3:57 PM, Blake Sullivan <[EMAIL PROTECTED]> 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
