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