jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Date Fri, 21 Apr 2006 15:02:41 GMT
On 4/21/06, Felix Satyaputra <f_satyaputra@yahoo.co.uk> wrote:
> 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.

correct. note that the current synchronization scheme
(rwLock in SharedItemStateManager) has evolved all along.
in previous revisions concurrency was controlled by
synchronizing on the PM instance.

>
> 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.

not quite correct. i am against changing the current 'simple' db pm
approach as i have repeatedly pointed out.

<quote>
the goals of the SimpleDbPersistenceManager implementation have been,
as its name suggests, being *simple*, having zero deployment requiremnts
and minimal dependencies. it's predestined to be used with embedded
databases such as e.g. Derby.
...
i wouldn't be against a more elaborate JDBC based PM implementation that makes
use of J2EE infrastructure features such as JNDI lookup of the DataSource, etc.
</quote>

feel free to contribute a jdbc-based pm that makes use of connection pools ;-)

re concurrency and pooled connections:

the write operations of the jdbc-based pm must occur within a single
db transaction,
i.e. you can't get a new connection for every write operation.

>
> Thanks for entertaining me!

my pleasure :-)

cheers
stefan
>
> Cheers,
>
> Felix
>
>
>
> ___________________________________________________________
> NEW - Yahoo! 360 – Your one place to blog, create, publish and share! http://uk.360.yahoo.com
>

Mime
View raw message