David,

> Either you can't get a connection due to misconfiguration or the server
> dying or a connection died and the driver didn't notice. Due to adapting
> firebird to xa semantics the driver doesn't actually make a connection
> until it knows what transaction you are working in.

Some of Mandips problems are emphasised that our tests only fail on some
machines and they do not fail in the same place.

But they do all fail on executing the first statement on a connection.

I am concerned that this way of not actually creating a connection until
it is used has a number of side effects

1. A normal connection pool will not help as the connections put in the
pool initially don't really exist so until they have all been used at
least once they a) might fail b) will cause delays

2. The only logicals place to check for good connections is when they
are created and when they are taken out of/put back into the pool. But
this is no longer possible. Now we have to check for connection failure
in our statement execute. That is different to every other JDBC driver
and is completely counter intuitive for developers. Statements should
fail because of SQL syntax problems, deadlocks etc not for connections
that appeared to have been created OK.

Does this really have to work this way? I know you keep extolling the
wonders of this XA architecture but it just seems to mean that normal
JDBC functionality does not work and every open source application I
have worked with (10 or so) uses that. In fact JBOSS is the only one
that I know of that does not BUT that is full J2EE which is not
something we and many others are interested in at all.

Please don't get me wrong. I do very much appreciate the work on this
driver. However, in order to get standard JDBC behaviour working I am
willing for Mandip to spend some time helping with this driver so that
it works more like a normal JDBC driver. How/where should he start?

Thanks

Dave