Lew wrote:
The question isn't can you use Hashtable, but why would you?
Thanks to all for the answers. I'm using HashMap for now, but here is what
my /ideal/ implementation would allow:
. Multiple threads should be able to /insert/ into the Map in parallel
. Attempts to /query/ the Map should not fail (return null) as long as
any other thread is in the middle of inserting...
Here is the explanation... My application has to send questions to an
external service, which replies asynchronously (some questions are easier
to answer than others).
Upon submitting a question, the service's API returns a correlation ID,
which the response will also bear.
To match the received replies with the asked questions, I'm using a
Map<CorrelationID,MyObject>.
Once in a blue Moon, an answer would come back to the replies-processing
thread /before/ the questions-asking thread had the chance to finish
inserting the ID into the Map. The replies-processing thread then treated
the reply as "unsolicited", etc.
I've switched to synchronized HashMap for now, but that means, only one
thread can be accessing the Map at any moment, which introduces some
unnecessary stalling: only one thread can be asking the question or
matching up the reply.
The app is quite fast anyway, but I'd like to know, if what I'm asking for
is possible in theory and, better yet, if ready implementations exist...
Thanks!
-mi
*before* announcing that its available. You might also consider using a