Hi Stefan,
> concurrent read operations are allowed if there's no
> current
> write operation or if the reading and writing thread
> are
> identical.
>
> code snippet from SharedItemStateManager:
>
> /**
> * Read-/Write-Lock to synchronize access on
> this item state manager.
> */
> private final ReadWriteLock rwLock =
> new
> ReentrantWriterPreferenceReadWriteLock() {
> /**
> * Allow reader when there is no
> active writer, or current
> * thread owns the write lock
> (reentrant).
> */
> protected boolean allowReader() {
> return activeWriter_ == null
> || activeWriter_ ==
> Thread.currentThread();
> }
> };
I see! So that's what allowReader() is for!
> > Am I understanding this correctly? So it's not the
> > PersistenceManager's responsibility to manage the
> > concurrency of the read/write operation?
>
> correct.
I'm trying to understand how all of this work in
conjunction with DB File System and DB Persistence
Manager, so kindly excuse me if the next question
sounds pretty basic.
Since the SharedItemStateManager controls the
read/write lock, this means there is no need for
locking within Persistence Manager.
My question is, why would there be a need to keep
single db connection in the DB File System and
Persistence Manager? Is there a reason beyond
concurrency issues?
When I read the gmane thread you sent to me, my
understanding is the single db connection is there due
to concurrency issues.
Thanks for entertaining me!
Cheers,
Felix
___________________________________________________________
NEW - Yahoo! 360 Your one place to blog, create, publish and share!
http://uk.360.yahoo.com
