On 2002.03.21 06:31:38 -0500 David Warnock wrote:

> 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

The delay is certainly in a different place than if the physical connection
was made when the connection was requested, but certainly the total time
taken and existence of an error is the same.

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

Connections can fail at any time. You have to check for connection failure
whenever you try to use the connection anyway. What happens to your app
when the network connection to the db server goes down?

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.

I'll say it again, connections can fail at any time.

>
> Does this really have to work this way?

Well, IMO the ideal solution is for development on fb2 to proceed to the
point where work on any transaction can be done over any connection. Then
a ManagedConnection can be permanently associated with a physical
connection. I don't know of any way to change the current behavior with
the current firebird and still keep reasonable xa performance.

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.

Although the timing of errors is different from what you are used to I
don't see you explaining what spec-required jdbc functionality doesn't work
with regards to requesting connections.

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.

Have you tried it? In combination with tools like xdoclet you might find in
speeded up development and modularized your app.

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

I think you should concentrate on finding out why some of the connections
are broken rather than trying to change the architecture of the driver. My
purpose in writing (my parts) of the driver are to provide a reliable easy
to use xa driver for a reliable database for use in jboss and possibly
other jca compliant app servers. In line with that goal, I am extremely
reluctant to add anything that would compromise xa performance. For
instance, I vigorously resisted implementing autocommit functionality until
requirements for it were added to the jca spec. I've tried really hard to
make sure that the bits implementing "normal" jdbc functionality such as
the Driver class and a standalone DataSource are wrappers around and do not
affect the underlying xa jca driver.

Anyway, what I would do to try to find out why these errors are occurring
is

1. In ManagedConnectionFactory.getDBHandle, add some logging code to
indicate when a new physical connection is being created. (you might be
able to use some existing logging from GDS_Impl, however adding logging
here will probably be easier to follow). This will let you easily
determine whether the broken connections are new or recycled.

2. If they are new, why are some connections getting created successfully
but others not? I have no idea-- a hardware problem?

3. If they are recycled, was some statement executed that broke them?
There is supposed to be a mechanism that determines if a non recoverable
error occurs on a connection and destroys it, however I don't think I
implemented it.

4. It is quite possible that there are other problems in the driver,
perhaps with insufficient synchronization.

Are all the connections created for the same db user? It just occurred to
me that I may not have implemented everything needed for properly managing
multiple users from the same Driver/DataSource instance.

I'm very interested in getting any problems with the driver fixed, however
I am not yet convinced that changing its architecture is the best way to
solve your problem. Can we please find out what is wrong before proposing
solutions?

Thanks
david jencks

>
> Thanks
>
> Dave
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>