I have to implement a sort of blocking mechanism in my web app to temporarily restrict access to servlets and JSP when application goes on maintenance (during backup data loading, unlodaing, etc...). The first idea that came into my mind was to use ServletContext#setAttribute and ServletContext#getAttribute methods along with interceptor filter, who could check the current blocking status attribute value and forward incoming request to destination action servlets or redirect them to the maintenance page when needed.
However, this approach has its drawbacks: some servlets may change the status data from time to time, and since each request generates its own thread, there must be a lot of synchronization on ServletContext object involved to protect status attribute. When I say "protect", I mean "make is thread-safe". Just let me put it more clear: from the very moment one thread begins updating the status variable in ServletContext, all other threads that might intervene in the process must retreat and wait until the first thread is finished with updating, so that not to read the old version of the status that is currently being updated...
Generally, from what I read, ServletContext attributes are not welcomed to be used as "updatable" data, and mostly serve as a storage for context-scoped objects (such as DataSource, for example), that are loaded once when context is being initialized and then used for reading (thus, not likely to change in the future).
So, now I'm searching for the alternatives to share updatable context data. So far, I've taken a brief look at synchronized collections, concurrent maps, database transactions with proper isolation level... but still not sure, which would be the best strategy to chose?