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 > > >
