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
<[EMAIL PROTECTED]> 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 <[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
