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?