OK, I seem to have satisfied my need to argue, on further reflection I
think that getting a physical connection when a ManagedConnection is
created will not hurt app server performance. However, note that the
connection you end up using may not be the one created when the
Connection/ManagedConnection is requested.

I'll see if I can add this later today.

I think you still need to figure out why some connections are broken,
though.

Thanks
david jencks

On 2002.03.21 08:49:01 -0500 David Jencks wrote:
> 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/
> >
> >
> >
> >
> >
>
>
> 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/
>
>
>
>
>