jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Thoughts on database persistence
Date Sat, 18 Mar 2006 14:22:22 GMT
Hi,

I just added JNDI/DataSource -based versions of the database
persistence manager and file system classes as requested in JCR-313.
The comments on the issue thread got me thinking about the current
"simple" approach and database configurability in general. The
database file system classes are pretty much mirrors of the
persistence manager counterparts, so I'll just focus on the PM classes
here, the same ideas apply to both situations.

The JCR-313 issue thread focused much on the question of
implementation "simplicity". After going throught the code I think the
question has more to do with the approach of keeping the database
connection throughout the PM lifecycle and caching prepared statements
for performance rather than any inherent simplicity of the
implementaion approach. The main point seems to be that the current
implementation wants to prepare the used statements once during
initialization rather than once per method call. This is somewhat in
conflict with the J2EE best practice of keeping a database connection
and related resources like prepared statements only for the duration
of a single operation.

Incidentally there happens to be one approach that would keep the
performance advantages of the current approach, remove the conflict
with J2EE practices, and even simplify the implementation! Like this:

1) Change the DatabasePersistenceManager to get a database connection
and prepare the used statements per each operation to comply with J2EE
practices.

2) Use the Commons DBCP DriverAdapterCPDS DataSource implementation
with PreparedStatement pooling in SimpleDbPersistenceManager to keep
the performance gains.

3) Remove the now unneeded Connection and PreparedStatement members
and resetStatement() method from the DatabasePersistenceManager class
to simplify the implementation.

The cost of this change would be a bit of pooling overhead per each
persistence manager operation (should be insignificang compared to the
cost of the database operations) and the introduction of commons-dbcp
and commons-pool as dependencies.

This change would also clarify that the responsibility of any extra
database shutdown operations like in the current
DerbyPersistenceManager rests on the subclass as the
DatabasePersistenceManager class would no longer keep any stable
reference to the underlying database.

What do you think? I can take a shot at implementing this if you think
it's worth doing.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Mime
View raw message