FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Hi Freddy, 

>   I'm just thinking about caching for auto discoveries and port
> instances. Our implementation for protocol discovery require fail&try in
> order to get correct protocol while instance detect require a query to
> server for every connection. 

I'm not sure I think maintaining a cache is worth the trouble.  The user
who wants to avoid the delay -- and it's not a long delay -- can do so by
stating the TDS version in freetds.conf.  The user who wants the
convenience of "TDS Version = auto" can afford to wait.  

My concern with a cache is the potential for confusion.  It's hard enough
today to understand how FreeTDS determines the TDS version.  Think of
TDS_Version in odbc.ini, freetds.conf, TDSVER, --with-tds-version.  In a
DSN-less environment, you can set up everything "right" and still fail to
connect because the compiled-in TDS version wasn't overridden at run time.
 

I'd also like to see autodetection successfully used in one full release
before we take the next step of caching its results.  

Still, it's worth considering.  If we are ever to get to a point where the
user need not specify the TDS version -- and still be as fast at
connecting -- we need a way to cache the discovery results.  My thoughts
below.  

> A good way to avoid these extra round-trips
> is to cache somewhere. The cache should be a lookup table with
> - ip of server (we don't want to cache even dns...)
> - port or instance
> - real port (for instance)
> - last protocol version
> - a "last time" for cleanup and updates

Instead of one file, I propose a directory, with one file for each server.
 The inode will hold the "last update" time, and it won't be necessary to
scan the file to find the server.  

I would write to /var/freetds/cache/<ip> if writable by the process, else
${HOME}/.freetds/cache/<ip>[:<instance>].  The file need contain only the
port number and the TDS version.  

(We could also move ~/.freetds.conf to ~/.freetds/config.)

> Should we add an additional configuration to store the path?

Not until a clear need presents itself.  

> - how to implement the cache, in a binary way or in a character format??

Character, absolutely definitely.  

> while some process should also update it and this require file locking
> for every update. 

An alternative: have a utility build/maintain the cache.  It could even be
run in cron.  

Either way, by using one file per server/instance, we can just lock the
file and not worry about byte ranges. (You know that file locking will be
yet another portability hassle, right?)  Also, I'm not aware of any kind
of file lock that isn't advisory.  There's nothing except an open
descriptor that prevents rm(1) from deleting the file you were going to
read.  

Regards, 

--jkl