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 > >> > > >
