Cris,
On 4/16/21 15:13, Berneburg, Cris J. - US wrote:
cs> You can also use thread-safe classes which either implement
cs> their thread-safety in one of a few different ways, synchronized
cs> blocks being one of those strategies.
Got any buzzwords for me that I can lookup "one of a few different ways", other
than synchronized blocks?
Stick with what you know. Only solve performance problems if you can
actually detect them. Anything else is premature optimization.
cs> "freshen" the data from the database if it had been altered by
cs> some other process e.g. an update from a database where new
cs> content is added, then migrated into production via direct SQL
cs> drop. So it really was a "reload" operation. These days, it's an
cs> "unload" operation. :)
I was wondering about that. Sounds like it basically invalidates the cache so
it can be reloaded later when needed.
That is precisely what it does. It used to proactively reload everything
from the database and replace what was there with a new set of objects.
Now, it's conceptually doing this:
context.getAttribute("myMapOfStuff").clear();
After that, any requests that object received to get a cached value goes
back to the original data-store and starts caching again.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
