All,

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?

thanks,

sm

Reply via email to