jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Database PersistenceManagers (was "Results of a JR Oracle test that we conducted)
Date Mon, 12 Mar 2007 13:31:22 GMT
Hi,

On 3/3/07, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> i don't see how getting & releasing connections in every load, exists and store
> call would improve preformance. could you please elaborate?
>
> please note that you wouldn't be able to use prepared statements over multiple
> load, store etc operations because you'd have to return the connection
> at the end of every call. the performance might therefore be even worse.

With a decent connection pool those get/release operations would be
very fast since most of the time you'd just be getting and releasing
existing database connections and prepared statements. I think the
pooling overhead should be very minor and easily countered by gains in
concurrency.

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

I think this is a design flaw. On the other hand we require
persistence managers to be "dumb" components, but then we rely on them
for complex features like transactions.

IMHO we should be looking at ways to make Jackrabbit properly
transactional already on top of the persistence layer. As Stefan
mentioned, this would imply changing not only the database persistence
managers, but also the item state management higher up the call chain.

As mentioned in my previous message, I'd be very interested in seeing
what such changes would mean in practice. It's probably a lot of work
but there aren't be any fundamental reasons why such changes couldn't
be implemented.

BR,

Jukka Zitting

Mime
View raw message