Sorry I wasn't as clear as I could have been - I realise JEE servers use
a threadpool for handling requests, I was thinking of many other applications
in the real world I'm aware of that don't (be that good design or otherwise...).
I'm not sure I follow you though when you say "it won't even do a write"
on a cache miss, it copies the (potentially stale) HashMap in that situation
does it not?
I still think there are some *theoretical* dangers (eg a thread replacing
a well populated cache with a stale/empty copy). Just consider me pessimistic
after having been burnt in the past by similar 'impossibilities' ;-) Overall
though I'm in agreement that there aren't any practical issues with this
code and in fact it'll give a good performance boost over String.intern()
even in the worst case anyway! I was only trying to raise the stale/visibility
issue but it's clear you've already given that plenty of thought.
On Sun, Apr 19, 2009 at 23:42, Chris Miller <chris.mil...@kbcfp.com>
wrote:
As soon as all possible fields are in the pool, we're essentially
readonly.
The problem is, there's no guarantee we will ever reach this point.
For example suppose you have a server app that spawns a new thread
per request. Each new thread might have to make all the .intern()
calls again because they never see anything in the cache.
No sane server app is actually spawning a new thread per request, it
takes one from pool. A spawned thread inherits visibility of its
parent thread (at the moment of spawning). Even if a new thread still
sees stale pool, it'll be updated on first cache miss. It won't even
do a write. So, no "all the intern calls again", such scenario doesn't
exist even in theory.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
