Nino wrote:

JSP means Web app which means plan for concurrent access.

Tradeoffs are complicated. You can cluster/farm app servers more easily than
data stores, but data stores can be scaled pretty high and have awesome
built-in caches. One way may be somewhat slower for a given user but allow
better interleaving of concurrent users, so overall throughput improves.
Caching things in application memory may speed up a user but limit the number
of concurrent requests that fit.

Naive expectations of performance often collapse in the face of massive
concurrent access.

Optimizations can occur both horizontally, e.g., throwing more servers at the
web layer, or vertically, e.g., the proposed memory caching scheme or using a
faster JDBC driver, or follow some other pattern, e.g., throwing edge caches
into the mix.

Andre's answer also hints at the difficulties of information latency and
synchronization. How "soon" "after" a transaction should a user see the
result? (In physics, relativity shows that frames of reference in relative
motion can view events as simultaneous or not if the time interval is less
than the "speed of light" latency in any frame of reference. Something similar
pertains to information simultaneity, information latency and cognitive
information processing. Consider Java's "happens-before" thread synchrony as
an example.)

It remains a dark art.

- Lew