Jukka Zitting
Mon, 12 Mar 2007 05:31:48 -0800
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