To follow up on my own question, which wasn't answered.
Closer examination of the Java driver (*) reveals that it doesn't throw BaseXExceptions (anymore?). Our code catches those (BaseXException is a subtype of IOException) and IOExceptions separately. I assume that an earlier version of the driver did (?). Looking through the code, IOException are thrown by most all methods.
Is it correct to assume that *any* IOException thrown leaves the BaseXClient object in an unusable state, thus requiring its replacement in the pool?
May I repeat my suggestion that you move this *crucial* piece of code out of the "examples" section and make it part of the properly supported/documented code base? As far as I'm concerned, with the concern and limitations about XQJ, *this* should be part of the officially sanctioned Java API.
- Godmar
(*) https://github.com/BaseXdb/basex-examples/blob/master/src/main/java/org/base...
On Sat, Feb 11, 2012 at 8:30 AM, Godmar Back godmar@gmail.com wrote:
Hi,
I have a question about the BaseX server. We're using it from a J2EE application (which is the client), and so we've implemented a connection pool in the style done by many other database drivers.
We are getting Broken Pipe errors, indicating that a connection has been disconnected. My question: when does BaseX disconnect, and is there a way for a client to learn this? For instance, if there's a syntax error in a XQUERY, should BaseX disconnect? If a BaseXException is thrown by the Java driver? Currently, we mark the connection as dead when an IOException or EOF occurs during the handling of one request, but we keep it alive when a BaseXException occurs, such as when we submit an ill-formed XQUERY.
We could avoid pooling, connecting and disconnecting for every query, but obviously that would be expensive. Or we could "ping" the server before issueing the actual query, but that's awkward, too.
How do others handle this problem?
- Godmar