hi martijn, On 8/22/07, Martijn Hendriks <[EMAIL PROTECTED]> wrote: > Hi all, > > Recently we discovered that our server application needs to be restarted > if Jackrabbit looses its database connection (which was already > documented in JCR-940). We really need the reconnection logic and > created a patch (feedback much appreciated :)). As a side effect of this > we also noticed the following w.r.t. the query system: The current > implementation of the LazyScoreNodeIterator is such to ignore all > RepositoryExceptions that might be thrown while loading the nodes in the > result set, as required by the javax.jcr.NodeIterator spec. For the use > case where the database connection is lost, the iterator thus gives an > incomplete result: only the nodes that are currently cached are > returned. > > The incomplete search result that is due to a lost connection is bad for > us as our app caches search results which we know to be stable. This can
i agree that this is a problem. > be solved by letting the persistence managers block while there's no > database connection available. (The patch for JCR-940 does not do this, > however). Of course this has its advantages and disadvantages; maybe the > PMs behaviour w.r.t. a lost connection should be configurable via the > repository.xml? i don't think that a call to the PM should unconditionally block if it lost the connection to the backend. it should report the error if it didn't succeed in re-establishing the connection. otherwise JCR api calls could potentially block forever. wrt to your problem: you could e.g. compare the value returned by NodeIterator#getSize with the number of successful #nextNode calls in order to detect skipped entries. however, entries could be skipped for other reasons (like e.g. access control). cheers stefan > > Best regards, > > Martijn > > -- > > Martijn Hendriks > <GX> creative online development B.V. > > t: 024 - 3888 261 > f: 024 - 3888 621 > e: [EMAIL PROTECTED] > > Wijchenseweg 111 > 6538 SW Nijmegen > http://www.gx.nl/ >
