Skip to Content.
Sympa Menu

freetds - RE: [freetds] dump file is per-spid

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO Frediano" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] dump file is per-spid
  • Date: Tue, 16 Dec 2003 12:27:32 +0100

>
> I bumped into unexpected (to me) behavior with TDSDUMP.
>
> If a single process opens two db-lib connections, the dump
> file is reopened when the second connection is established.
> Our documentation says this is "process" related; I assumed
> "process" meant client process, not spid. [1]
>
> I can see why we wouldn't want several client processes
> recording to the same log. But I think it's a mistake to
> initialize the log every time we connect to the server. I
> can't see what use that is.
>
> For db-lib, we should probably initialize the log logically
> during dbinit(). For ct-lib, ct_init(). For ODBC? I suppose
> we need a tds_init() for them all to call, as long as it's
> not an error to call tds_init() multiple times.
>
>
> It occurs to me that client-side iconv initialization could
> be per client process, too. Right now, it's per-connection.
>
> I suppose this is all 0.63 stuff. Any comments on my
> proposed functionality?
>

I think it's a big problem. We have "dump file" options for every
connection however we use these information to initialize a single
global file. So the re-open occurs... The simplest way to remove this
problem is to use only a global dump (not for every connection). This
mean to remove dumpfile fields from tds_connect_info/login_info and
accept it only on global section. Another problem is related to thread.
We write process id in log so to detect differents process (as in
apache) however on multithreaded environments where getpid() on thread 1
== getpid() on thread 2 (ie apache2 using thread and linux with native
posix thread support) it's impossible to detect which thread did the
operation.

About iconv. We have a global initialization (using a static variable to
test) and per-connection initializations. Considering that
- a server can have differents encodings
- every connection can have a different client charset
- some charset has a state (you can't use same iconv converting two
string without resetting the state)
- some conversions must be freed when connection is closed
- TDSCOLINFO->iconv_info point to a iconv structure without and
reference count or such
perhaps it's better to leave per-connection iconv as it is... Or just
post to 0.63...

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page