Re: ReadWriteLock rather on map's each field than whole map?
- From: Hunter Gratzner <a24900@xxxxxxxxxxxxxx>
- Date: Sat, 29 Sep 2007 18:25:07 -0000
On Sep 29, 7:45 pm, easy <easy....@xxxxxxxxx> wrote:
In ConcurrentHashMap.put(...) it uses a lock,
so there is no real "concurrent" put() posible.
right?
No. You haven't sad what kind of lock. You haven' sad what the lock is
used for and when. The lock might protect a few critical section under
special conditions. And francly sad, I do trust the API documentation
more than I trust you. And the API documentation states that the class
supports concurrent updates.
Further, you have stated that the DB access is the time consuming
task. Why are you concerned about a likely very short, if any, write
lock in the map, if the DB access before the write takes "ages"? It
maybe could make a difference when the cache is initially empty. But
only maybe, and once the cache is loaded a write to the map should be
a rare occurrence. If a write is not a rare occurrences than the whole
cache maybe doesn't make sense.
Again, get a good book on Java multi threading. Alternatively refrain
from using multi threading.
.
- Follow-Ups:
- References:
- ReadWriteLock rather on map's each field than whole map?
- From: easy
- Re: ReadWriteLock rather on map's each field than whole map?
- From: Hunter Gratzner
- Re: ReadWriteLock rather on map's each field than whole map?
- From: easy
- ReadWriteLock rather on map's each field than whole map?
- Prev by Date: Re: Great SWT Program
- Next by Date: Re: Method.invoke() with one arg compiles despite method signature
- Previous by thread: Re: ReadWriteLock rather on map's each field than whole map?
- Next by thread: Re: ReadWriteLock rather on map's each field than whole map?
- Index(es):
Relevant Pages
|
