You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Felix Satyaputra <f_...@yahoo.co.uk> on 2006/04/19 17:17:36 UTC
DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Hi All,
I've got a question about DbFileSystem and
SimpleDbPersistenceManager. It seems that these two
classes are holding on to the single db connection and
the bunch of prepared statement initialised during
startup (please correct me if I am wrong).
Is there a reason behind this? If the database
connection and prepared statements are pooled (using
dbcp, for example), would it break any compatibility
with the JCR specs?
If using connection pool would not break JCR
compatibility, isn't it better to just create
connection and prepared statements on the go? We then
can configure jdbc url and driver which points to
pooled connection like dbcp and proxool. The db pool
then can handle reusing connection and prepared
statements.
Any thoughts are appreciated.
Cheers,
Felix
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Posted by Stefan Guggisberg <st...@gmail.com>.
On 4/24/06, Felix Satyaputra <f_...@yahoo.co.uk> wrote:
> Hi Stefan,
>
> > > 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.
>
> Right. Is it possible in any way that the PM instance
> be notified of SharedItemStateManager's #begin(),
> #end(), and #cancel() operation?
why would you need that?
>
> Is there any listener interface to implement, or is it
> possible for a PM which implements a particular
> interface to be notified?
>
> I've looked at the listener interface which is there
> but there is none which allows me to do this.
>
>
> > >
> > > 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 ;-)
> I'll give a shot on my end - when I managed to work it
> all out, I'll send you an email :)
>
>
> > 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.
> Which is why I am asking if there is any way for PM to
> be notified of SharedItemState manager's #begin, #end,
> #cancel :)
have a look at DatabasePersistenceManager's implementation
of PersistenceManager#store(ChangeLog). that's the hook
you're looking for...
cheers
stefan
>
> If there's a way, I have an idea which might make a
> JDBC pooled PM work according to JCR specs, fingers
> crossed!
>
> Cheers,
>
> Felix
>
>
>
>
>
> ___________________________________________________________
> Yahoo! Photos – NEW, now offering a quality print service from just 7p a photo http://uk.photos.yahoo.com
>
Re: DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Posted by Felix Satyaputra <f_...@yahoo.co.uk>.
Hi Stefan,
> > 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.
Right. Is it possible in any way that the PM instance
be notified of SharedItemStateManager's #begin(),
#end(), and #cancel() operation?
Is there any listener interface to implement, or is it
possible for a PM which implements a particular
interface to be notified?
I've looked at the listener interface which is there
but there is none which allows me to do this.
> >
> > 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 ;-)
I'll give a shot on my end - when I managed to work it
all out, I'll send you an email :)
> 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.
Which is why I am asking if there is any way for PM to
be notified of SharedItemState manager's #begin, #end,
#cancel :)
If there's a way, I have an idea which might make a
JDBC pooled PM work according to JCR specs, fingers
crossed!
Cheers,
Felix
___________________________________________________________
Yahoo! Photos NEW, now offering a quality print service from just 7p a photo http://uk.photos.yahoo.com
Re: DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Posted by Stefan Guggisberg <st...@gmail.com>.
On 4/21/06, Felix Satyaputra <f_...@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
>
Re: DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Posted by Felix Satyaputra <f_...@yahoo.co.uk>.
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
Re: DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Posted by Stefan Guggisberg <st...@gmail.com>.
hi felix,
On 4/21/06, Felix Satyaputra <f_...@yahoo.co.uk> wrote:
> Hi Stefan,
>
>
> > the .lock file has nothing to do with it. it just
> > prevents
> > multiple RepositoryImpl instantiation using the same
> > configuration.
> I see.
>
> > write operations on the persistence layer are
> > synchronized
> > on a higher level in order to guarantee data
> > consistency/
> > referential integrity (e.g. node references).
> >
> > see SharedItemStateManager#begin, #end and #cancel
> > methods.
> I've checked SharedItemStateManager#begin, #end and
> #cancel.
>
> So basically SharedItemStateManager manages the
> concurrency of the read/write operations by using the
> ReadWriteLock - within the same thread? I notice that
> the ReadWriteLock is being used in #begin, #end, and
> #cancel.
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();
}
};
>
> Am I understanding this correctly? So it's not the
> PersistenceManager's responsibility to manage the
> concurrency of the read/write operation?
correct.
cheers
stefan
>
> Cheers,
>
> Felix
>
> Send instant messages to your online friends http://uk.messenger.yahoo.com
>
Re: DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Posted by Felix Satyaputra <f_...@yahoo.co.uk>.
Hi Stefan,
> the .lock file has nothing to do with it. it just
> prevents
> multiple RepositoryImpl instantiation using the same
> configuration.
I see.
> write operations on the persistence layer are
> synchronized
> on a higher level in order to guarantee data
> consistency/
> referential integrity (e.g. node references).
>
> see SharedItemStateManager#begin, #end and #cancel
> methods.
I've checked SharedItemStateManager#begin, #end and
#cancel.
So basically SharedItemStateManager manages the
concurrency of the read/write operations by using the
ReadWriteLock - within the same thread? I notice that
the ReadWriteLock is being used in #begin, #end, and
#cancel.
Am I understanding this correctly? So it's not the
PersistenceManager's responsibility to manage the
concurrency of the read/write operation?
Cheers,
Felix
Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Posted by Stefan Guggisberg <st...@gmail.com>.
hi felix
On 4/21/06, Felix Satyaputra <f_...@yahoo.co.uk> wrote:
> Hi Stefan,
>
> Thanks for the pointer.
>
> Just to check if my understanding is correct, can I
> confirm one thing... In JCR spec, threads can read and
> attempt to write asynchronously into repository. But
> when changes is persisted, the change need to be
> applied synchronously (hence the lock file). Am I
> correct to say this?
the .lock file has nothing to do with it. it just prevents
multiple RepositoryImpl instantiation using the same
configuration.
write operations on the persistence layer are synchronized
on a higher level in order to guarantee data consistency/
referential integrity (e.g. node references).
see SharedItemStateManager#begin, #end and #cancel methods.
>
> If my understanding is correct, can I closely follow
> the behaviour above by doing the following when doing
> read and write in DbFileSystem and DB Persistence
> Manager?
>
> 1. Reopen new JDBC Connection (or reuse from pool)
> 2. Set autocommit to false
> 3. Set transaction isolation to
> TRANSACTION_READ_COMMITED
> 4. Execute all statements required
> 5. Commit the changes
>
> Is this possible?
sorry, can't follow you here. i don't know exactly what you're up to.
cheers
stefan
>
> Cheers,
>
> Felix
>
>
> --- Stefan Guggisberg <st...@gmail.com>
> wrote:
>
> > On 4/19/06, Stefan Guggisberg
> > <st...@gmail.com> wrote:
> > > hi felix,
> > >
> > > these topics have been discussed extensively in
> > the dev list.
> > > check out e.g.
> >
> http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6166/focus=6172
> >
> > sorry, the correct pointer is:
> >
> http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6166/focus=6166
> >
> > more pointers:
> > http://issues.apache.org/jira/browse/JCR-313
> >
> http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/5414/focus=5452
> >
> > cheers
> > stefan
> >
> > >
> > > cheers
> > > stefan
> > >
> > > On 4/19/06, Felix Satyaputra
> > <f_...@yahoo.co.uk> wrote:
> > > > Hi All,
> > > >
> > > > I've got a question about DbFileSystem and
> > > > SimpleDbPersistenceManager. It seems that these
> > two
> > > > classes are holding on to the single db
> > connection and
> > > > the bunch of prepared statement initialised
> > during
> > > > startup (please correct me if I am wrong).
> > > >
> > > > Is there a reason behind this? If the database
> > > > connection and prepared statements are pooled
> > (using
> > > > dbcp, for example), would it break any
> > compatibility
> > > > with the JCR specs?
> > > >
> > > > If using connection pool would not break JCR
> > > > compatibility, isn't it better to just create
> > > > connection and prepared statements on the go? We
> > then
> > > > can configure jdbc url and driver which points
> > to
> > > > pooled connection like dbcp and proxool. The db
> > pool
> > > > then can handle reusing connection and prepared
> > > > statements.
> > > >
> > > > Any thoughts are appreciated.
> > > >
> > > > Cheers,
> > > >
> > > > Felix
> > > >
> > > >
> > > >
> > > >
> >
> ___________________________________________________________
> > > > To help you stay safe and secure online, we've
> > developed the all new Yahoo! Security Centre.
> > http://uk.security.yahoo.com
> > > >
> > >
> >
>
>
>
>
> ___________________________________________________________
> NEW - Yahoo! 360 – Your one place to blog, create, publish and share! http://uk.360.yahoo.com
>
Re: DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Posted by Felix Satyaputra <f_...@yahoo.co.uk>.
Hi Stefan,
Thanks for the pointer.
Just to check if my understanding is correct, can I
confirm one thing... In JCR spec, threads can read and
attempt to write asynchronously into repository. But
when changes is persisted, the change need to be
applied synchronously (hence the lock file). Am I
correct to say this?
If my understanding is correct, can I closely follow
the behaviour above by doing the following when doing
read and write in DbFileSystem and DB Persistence
Manager?
1. Reopen new JDBC Connection (or reuse from pool)
2. Set autocommit to false
3. Set transaction isolation to
TRANSACTION_READ_COMMITED
4. Execute all statements required
5. Commit the changes
Is this possible?
Cheers,
Felix
--- Stefan Guggisberg <st...@gmail.com>
wrote:
> On 4/19/06, Stefan Guggisberg
> <st...@gmail.com> wrote:
> > hi felix,
> >
> > these topics have been discussed extensively in
> the dev list.
> > check out e.g.
>
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6166/focus=6172
>
> sorry, the correct pointer is:
>
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6166/focus=6166
>
> more pointers:
> http://issues.apache.org/jira/browse/JCR-313
>
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/5414/focus=5452
>
> cheers
> stefan
>
> >
> > cheers
> > stefan
> >
> > On 4/19/06, Felix Satyaputra
> <f_...@yahoo.co.uk> wrote:
> > > Hi All,
> > >
> > > I've got a question about DbFileSystem and
> > > SimpleDbPersistenceManager. It seems that these
> two
> > > classes are holding on to the single db
> connection and
> > > the bunch of prepared statement initialised
> during
> > > startup (please correct me if I am wrong).
> > >
> > > Is there a reason behind this? If the database
> > > connection and prepared statements are pooled
> (using
> > > dbcp, for example), would it break any
> compatibility
> > > with the JCR specs?
> > >
> > > If using connection pool would not break JCR
> > > compatibility, isn't it better to just create
> > > connection and prepared statements on the go? We
> then
> > > can configure jdbc url and driver which points
> to
> > > pooled connection like dbcp and proxool. The db
> pool
> > > then can handle reusing connection and prepared
> > > statements.
> > >
> > > Any thoughts are appreciated.
> > >
> > > Cheers,
> > >
> > > Felix
> > >
> > >
> > >
> > >
>
___________________________________________________________
> > > To help you stay safe and secure online, we've
> developed the all new Yahoo! Security Centre.
> http://uk.security.yahoo.com
> > >
> >
>
___________________________________________________________
NEW - Yahoo! 360 Your one place to blog, create, publish and share! http://uk.360.yahoo.com
Re: DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Posted by Stefan Guggisberg <st...@gmail.com>.
On 4/19/06, Stefan Guggisberg <st...@gmail.com> wrote:
> hi felix,
>
> these topics have been discussed extensively in the dev list.
> check out e.g. http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6166/focus=6172
sorry, the correct pointer is:
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6166/focus=6166
more pointers:
http://issues.apache.org/jira/browse/JCR-313
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/5414/focus=5452
cheers
stefan
>
> cheers
> stefan
>
> On 4/19/06, Felix Satyaputra <f_...@yahoo.co.uk> wrote:
> > Hi All,
> >
> > I've got a question about DbFileSystem and
> > SimpleDbPersistenceManager. It seems that these two
> > classes are holding on to the single db connection and
> > the bunch of prepared statement initialised during
> > startup (please correct me if I am wrong).
> >
> > Is there a reason behind this? If the database
> > connection and prepared statements are pooled (using
> > dbcp, for example), would it break any compatibility
> > with the JCR specs?
> >
> > If using connection pool would not break JCR
> > compatibility, isn't it better to just create
> > connection and prepared statements on the go? We then
> > can configure jdbc url and driver which points to
> > pooled connection like dbcp and proxool. The db pool
> > then can handle reusing connection and prepared
> > statements.
> >
> > Any thoughts are appreciated.
> >
> > Cheers,
> >
> > Felix
> >
> >
> >
> > ___________________________________________________________
> > To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
> >
>
Re: DbFileSystem and SimpleDbPersistenceManager - Connection and PreparedStatement
Posted by Stefan Guggisberg <st...@gmail.com>.
hi felix,
these topics have been discussed extensively in the dev list.
check out e.g. http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6166/focus=6172
cheers
stefan
On 4/19/06, Felix Satyaputra <f_...@yahoo.co.uk> wrote:
> Hi All,
>
> I've got a question about DbFileSystem and
> SimpleDbPersistenceManager. It seems that these two
> classes are holding on to the single db connection and
> the bunch of prepared statement initialised during
> startup (please correct me if I am wrong).
>
> Is there a reason behind this? If the database
> connection and prepared statements are pooled (using
> dbcp, for example), would it break any compatibility
> with the JCR specs?
>
> If using connection pool would not break JCR
> compatibility, isn't it better to just create
> connection and prepared statements on the go? We then
> can configure jdbc url and driver which points to
> pooled connection like dbcp and proxool. The db pool
> then can handle reusing connection and prepared
> statements.
>
> Any thoughts are appreciated.
>
> Cheers,
>
> Felix
>
>
>
> ___________________________________________________________
> To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
>