Hi,
On 3/3/07, Stefan Guggisberg <[EMAIL PROTECTED]> 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
