java - Is javax.servlet.ServletContext set/getAttribute thread safe? -

having use setattribute() , getattribute(string) in javax.servlet.servletcontext, cannot find information on intended behavoir concurrent access. however, these operations may called different threads.

the servlet specification 3.0 states:

a servlet can bind object attribute context name. attribute bound context available other servlet part of same web application.

however, there no information on concurrency behavior of these operations. source code of apache tomcat reveals implemented concurrenthashmap, making thread-safe.

my question is, should treat these operations not thread-safe , have application handle synchronisation, or there piece of information missing?

you can safely assume can call getattribute , setattribute without synchronizing on anything, should make objects store there threadsafe (the easiest way being store things immutable). question linked in comments storing mutable object in servletcontext, in case threads using need acquire lock first (which the accepted answer explains).

there's not spelled-out requirement. covered in java concurrency in practice, section 4.5.1 interpreting vague documentation:

you going have guess. 1 way improve quality of guess interpret specification perspective of implement (such container or database vendor), opposed merely use it. servlets called container-managed thread, , safe assume if there more 1 such thread, container knows this. servlet container makes available objects provide service multiple servlets, such httpsession or servletcontext. servlet container should expect have these objects accessed concurrently, since has created multiple threads , called methods servlet.service them reasonably expected access servletcontext.

since impossible imagine single-threaded context in these objects useful, 1 has assume have been made thread-safe, though specification not explicitly require this. besides, if required client-side locking, on lock should client code synchronize? documentation doesn't say, , seems absurd guess. “reasonable assumption” further bolstered examples in specification , official tutorials show how access servletcontext or httpsession , not use client-side synchronization.

on other hand, objects placed in servletcontext or httpsession setattribute owned web application, not servlet container. servlet specification not suggest mechanism coordinating concurrent access shared attributes. attributes stored container on behalf of web application should thread-safe or immutable. if container did store these attributes on behalf of web application, option ensure consistently guarded lock when accessed servlet application code. because container may want serialize objects in httpsession replication or passivation purposes, , servlet container can't possibly know locking protocol, should make them thread-safe.