Hi Sten, Normally we only backport bug fixes to the release branches, so probably not.
Best regards, Martijn On Thu, Dec 3, 2009 at 5:32 PM, Sten Martinez <[email protected]> wrote: > Martijn, > > any chance this will be back-ported to 1.6.x? > > thanks, > > sm > > On Thu, Dec 3, 2009 at 12:21 AM, Martijn Hendriks <[email protected]> wrote: >> >> Hi Sten, >> >> 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. >> >> Best regards, >> >> Martijn >> >> On Wed, Dec 2, 2009 at 8:22 PM, Sten Martinez <[email protected]> >> wrote: >> > 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 >> > > >
