FreeTDS Development Group

["Xu Behoneo" <behoneox AT hotmail.com>]

Hi, jkl

Of your points, sorry for that I'm not familiar with db-lib and ctlib. 

I'm using ODBC API to query a MSSQL database with FreeTDS as the driver, 
the timeout issue was brought when I calling SQLExecDirect and at such time 
the server is down, the SQLExecDirect will be blocked. I think maybe I need 
to set some timeout attributes, I look into the ODBC API documents, and 
find SQLSetConnectAttr can set timeout for a dbc handle, and SQLSetStmtAttr 
can set timeout for a statement handle. I set both, but the SQLExecDirect 
still block, I look into the freetds code and find that, I'm not sure 
whether this timeout should be apply to the driver. As you have said, maybe 
my application need to take some special operation for this case.

Thanks,
Behoneo


> From: "James K. Lowden" <jklowden AT freetds.org>
> Reply-To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
> To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
> Subject: Re: [freetds] Time out issue
> Date: Thu, 30 Nov 2006 00:54:23 -0500
>
> Xu Behoneo wrote:
> >
> > I understand that the client needs to receive a cancel reply from
> > server,  but assuming that there is a network failure or server down, 
it
> > will block  until everything works fine. I think this isn't a good
> > behavior, of course  return immediately isn't appropriate also. Maybe 
we
> > can still specify the  second select a timeout, and if it timeout also,
> > then we can return.
>
> Perhaps.  You'd need to point me to some relevant documentation, though.
>
> We don't make up library behavior; we try to conform to specifications.
> For db-lib, there are two:
>
> 1.  dbsetlogintime(), how long to wait for an answer to a login request
> 2.  dbsettime(), how long to wait for a query to execute.
>
> You're using ODBC.  If you can point out a timeout value that the FreeTDS
> ODBC driver isn't honoring correctly -- i.e., according to the ODBC
> specification -- I'm sure we'd want to look at it.
>
> The idea, I believe, is that the timeouts apply to server operations, not
> network behavior.  The client may connect to a remote port where no server
> is responding.  When to stop waiting for a reply is up to the application.
>  How long to wait for a query to execute is, too.  Network timeouts --
> such as how many times a packet is resent and how long to wait for an
> acknowledgement -- are controlled by tcp/ip timeouts that are built into
> the network stack.
>
> Specifically, dbsettime() does *not* apply to cancel messages.
> (http://manuals.sybase.com:80/onlinebooks/group-cnarc/cng1110e/dblib/@Gen
> eric__BookTextView/39238;pt=9393#X)  That's consistent: it's expected that
> the server can respond in timely manner to the cancel message.
>
> If the network goes down when the cancel message is sent, tcp/ip will
> eventually return some kind of error[1].  That will be propagated up the
> FreeTDS layers, resulting in the API function returning a FAIL status.
>
> Sorry for such a long message.  You raised an important point, and I
> wanted to address it fully.
>
> --jkl
>
> [1] Depending on exactly what happened and whose tcp/ip implementation
> you're using, the retries could go on for hours, which might seem like
> forever but actually isn't.
>
>
> > >From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
> > >Reply-To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
> > >To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
> > >Subject: Re: [freetds] Time out issue
> > >Date: Wed, 29 Nov 2006 08:48:50 +0100
> > >
> > > >
> > > > Hi, all
> > > >
> > > > When I use the FreeTDS with unixODBC, I have a timeout
> > > > problem, I'm not sure whether this is a bug.
> > > >
> > > > The issue is in the "tds_goodread" function(src/tds/net.c),
> > > > when the "select" function returns because of timeout, the
> > > > "len" variable will be set to 0, and it will go into the "if"
> > > > section, in that, a query timeout function will be called,
> > > > without dblib, this function will always be
> > > > "query_timeout_cancel" function(src/odbc/odbc.c), and it set
> > > > the timeout of the tds socket to 0 and returns
> > > > "TDS_INT_CANCEL", so that in the former "if" section, a
> > > > cancel packet is sent, but it still in the loop and call
> > > > select again, but at this time, the timeout value is 0 and
> > > > select will wait forever.
> > > >
> > > > I think after called the "tds_send_cancel" call, it should
> > > > return immediately.
> > > >
> > > > Thanks,
> > > > Benheng Xu
> > >
> > >No, the behavior is correct. Assuming you send a query that take a lot
> > >of time, when timeout is reached you send cancel request and you have
> > >to wait for DONE with cancel reply from server. You cannot return
> > >immediately cause you break server syncro so you would end up in an
> > >inconsistent state.
> > >
> > >Frediano
> > >
> > >_______________________________________________
> > >FreeTDS mailing list
> > >FreeTDS AT lists.ibiblio.org
> > >http://lists.ibiblio.org/mailman/listinfo/freetds
> >
> > _________________________________________________________________
> > 免费下载 MSN Explorer:   http://explorer.msn.com/lccn/
> >
> >
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds

_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。  http://www.hotmail.com