Skip to Content.
Sympa Menu

freetds - Re: [freetds] Timeout for reading from the server doesn't work.

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Timeout for reading from the server doesn't work.
  • Date: Sun, 27 Nov 2005 15:02:07 +0100

Il giorno sab, 26/11/2005 alle 17.13 -0500, James K. Lowden ha scritto:
> entropy AT freetds.org wrote:
> > James K. Lowden wrote:
> > > Agreed. Keep in mind that the application's handler will be
> > > different, depending on whether it's db-lib or ct-lib. The rules are
> > > different, even though at the tds layer it all boils down to
> > > retry/abort. That's why each library needs its own intermediary to
> > > interpret the handler's return code and convert it into libtds's
> > > single form. To do that, libtds has to know which intermediary to
> > > call.
> > >
> > > application
> > > API library
> > > libtds
> > > goodread (or whatever)
> > > error
> > > determine API
> > > API intermediary
> > > application's error handler
> > > convert API return code to libtds code
> > > retry or abort
> > >
> > > I hope that's clear. Tell me if not.
> >
> > I agree with Freddy. The API return codes should never leave the API
> > and its applications. All interfacing to libtds should be done in the
> > callback routine that the API registered with libtds. Then there is no
> > need for libtds to know or care which API is involved, and it doesn't
> > need to be polluted with API-specific codes. The "API intermediary"
> > should be provided by the API itself, and all libtds then needs to do is
> >
> > call it.
>
> I'm not sure there's any disagreement.
>
> Each API has its own rules about error codes and return codes. I've
> looked at it carefully. The way the handler indicates how to proceed
> differs. I don't believe it's possible to unify them merely by choosing
> the #define constants carefully.
>
> If libtds were to call the handler directly, there's no opportunity for an
> intermediary to translate the handler's return code.
>

Now I understood your confusion. You are confusing application handler
with library handler... libtds call handler that library give so library
usually pass it's own handler, not application one directly.

> If we agree that 1) the handler's return codes will differ by API, by
> design, and 2) there should be a translation layer to convert them to a
> canonical form, and 3) that that translation layer (my intermediary)
> should reside in the API layer, then we should also agree that libtds
> needs to know which intermediary function to call. It can itself be
> registered (perhaps that's what you meant?) or libtds can know which is
> the controlling API and look up the appropriate intermediary.
>
> I had been thinking that libtds would look up the intermediary by API. I
> see now that the application can register with the client library, and the
> client library can register with libtds. I like that approach better; I
> wish someone had suggested it earlier.
>

This has been discussed and represent the current implementation. For
instance for dblib libtds calls dblib_query_timeout which calls client
dbchkintr/dbhndlintr.

> Either way, the call stack is the same:
>
> (app) handler
> (api) intermediary
> (tds) libtds error branch
> (tds) libtds
> (api) API
> (app) application
>

bye
freddy77






Archive powered by MHonArc 2.6.24.

Top of Page