Re: downsides/overhead of stashing & restoring (probably empty) ThreadContextMap ?

> On Nov 8, 2021, at 3:04 PM, Chris Hostetter <[email protected]> wrote:
> 
> 
> And if the ThreadContext is _not_ empty? ... is there anything about how 
> it's implemented that would make the initial map copy (and later 
> `putAll(...)` call) more "epensive" from a performance standpoint then an 
> off the shelf 'new HashMap?

Well, the cost is going to be dependent on how many items are in the Map. 
But, as I said, the reason nobody does this is because the Map is always 
empty unless you have another filter in front of it putting stuff in, in which 
case you have a bigger problem because your filter is ignoring what it is 
adding.

Your app should know what filters is using and what they do. The container 
is never going to add stuff to the ThreadContext. That is why it passes you 
an HttpRequest and you have a ServletContext. So it doesn’t need to put 
anything in the ThreadContext. But you very well may want to pull stuff out 
of those and add them to the ThreadContext so you don’t have to pass the 
HttpRequest to everything.

The bottom line is that you are being a good citizen by clearing the Map.

Ralph