jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: Thoughts on database persistence
Date Sat, 18 Mar 2006 16:11:48 GMT
On 3/18/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> 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.

'Simple' also refers to use of a very simple data model instead of
a fully normalized schema or some object-relational mapping.

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

those best practices apply to j2ee applications. the point is that i don't
consider jackrabbit to be a j2ee application, jackrabbit is infrastructure
and has other requirements regarding its persistence layer than a
database application.

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

note that write operations must occur within a single transaction, i.e.
you can't get a new connection for every write operation.

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

-1 for changing SimpleDbPersistenceManager as suggested right now

on the other hand i have problem with adding a new more sophisticated
db pm as suggested.

time and experience will tell if we want to keep them both or not.


> BR,
> Jukka Zitting
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development

View raw message