any chance this will be back-ported to 1.6.x?
This is a known problem (also see JCR-2226). A quite complete solution
for issue JCR-1456 (database connection pooling) has yesterday made it
into the trunk and is scheduled for the 2.0 release. This might very
well solve your problem.
On Wed, Dec 2, 2009 at 8:22 PM, Sten Martinez <email@example.com> wrote:
> i have been working with jackrabbit 1.6.0 recently in a commercial
> environment, and have run into some issues:
> - the single connection doesn't play well with Oracle OCM. OCM closes the
> connection, and the reconnect timout is entirely too long, especially with a
> bursting traffic load. jackrabbit doesn't periodically make sure it's
> connection is fresh, and the next group of hits will often cause a cascade
> of waiting threads.
> - the cluster journal's prepared statements are being collected or closed by
> Oracle, even when the connection is still valid. this results in
> unrecoverable errors, and the jackrabbit system gets out of sync.
> my question is: why does jackrabbit use the single connection anyway? do the
> prepared statements even confer a significant performance benefit with
> todays DBMS and hardware?
> i have had to make some customization to the 1.6.0 tag's code, to remove the
> use of prepared statements entirely in the journal, and as an exercise i did
> it in the rest of the system as well. also, i changed the executeStmt
> methods (now called executeSQL) to silently and easily get a new connection
> if the old one died. this way, "transactional" operations that relied on the
> constant connection will still work.
> is this on the roadmap for the 1.6.x branch, and if not, are you guys
> interested in moving in this direction?