Skip to Content.
Sympa Menu

freetds - RE: [freetds] Longstanding issue and 0.64...

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Longstanding issue and 0.64...
  • Date: Tue, 30 Nov 2004 16:43:05 +0100

> From: Lowden, James K
> Sent: lunedì 29 novembre 2004 20.03
>
> > From: ZIGLIO, Frediano, VF-IT
> > Sent: Monday, November 29, 2004 10:16 AM
> >
> > Now that we are more free I would like to discuss some longstanding
> > (big) changes. Mainly logging, thread-safe and row structure!
> >
> > Log:
> > - James open the question many time ago. If would be fine to filter
> > logs by type (network, data and so only) and not only on level
> > - log it's mainly global. Although you can configure log by
> connection
> > a new connection just override all opened logs (not that kind). This
> > make logging global and cause some problems for testing (setting log
> for
> > a connection cause logging for entire server). Also there is a small
> > memory leak allocating name of logging file. This will
> require to put
> > logging file name in TDSSOCKET and an additional TDSSOCKET*
> parameter
> to
> > logging functions
>
> I'd like the log to be opened once, when the library is initialized,
> unless we make the once-per-pid behavior standard.
>
> I think the log format should be standardized; it would be easier to
> grep and scan. I don't see much value in logging the time on every
> line. It's enough that we know when packets were sent and received.
>
> Here's a format suggestion:
>
> LEVEL PID Function (File:Line): text
>
> LEVEL would be one of:
>
> LOGIN
> API
> ASYNC
> DIAG
> ERROR
> PACKET
> LIBTDS
> CONFIG
>

What difference between API and LIBTDS ??

> Continuations of "text" would appear on succeeding lines,
> starting with
> a tab character.
>
> > (perhaps we need also to syncronize access to a single file)
>
> Surely stdio synchronizes writes to a file?
>

stdio ?? If I open 2 connection I need to write to the same file. If I use
same handle I'm sure it write correctly informations but if I open two
handles for the same file probably one write overwrite other write. Well...
I'm not sure but this thing need a bit of testing.

This simple program

#include <stdio.h>
#include <stdlib.h>

int main()
{
FILE *f1, *f2;
f1 = fopen("test.txt","a");
f2 = fopen("test.txt","a");
if (!f1 || !f2) {
fprintf(stderr, "file open error\n");
return 1;
}
fprintf(f1, "test1\n");
fprintf(f2, "test2\n");
fprintf(f1, "test3\n");
fprintf(f2, "test4\n");
fclose(f2);
fclose(f1);
printf("success!\n");
return 0;
}

output

test2
test4
test1
test3

It do not overwrite however sequence it's not correct.

> > - it would be fine to be able to disable compile of
> logging code for
> > embedded systems
>
> Right. If tdsdump() were called in the code via a macro, "TDSDUMP()",
> we could defeat logging with a #define. But are there any embedded
> systems?
>

At present not but some people use FreeTDS in some strange ways...
Also we need a macro to support file:line syntax...

> > Thread-safe:
> > - cancel function can be called from other thread or from signal...
> we
> > have to handle both situations safety...
>
> I don't think FreeTDS should catch signals. It's up to the
> application
> to catch signals and call the API accordingly. If we decide to use
> O_ASYNC, that's another story.
>

I know that it's up the application however dbcancel docs state that a code
inside a signal can call this function (to support alarm or similar) and
SQLCancel docs state that this function can be called from another thread
while connection it's busy.

> > Row structure:
> > - well there is few things to say. It's a shit! We did too
> job to use
> > the same packing method used for getting data and in some
> case we lose
> > IMHO too much memory. All library use to bind parameters
> for input so
> it
> > would be good to use these bindings and compute row on the fly. This
> for
> > rpc/dynamic sql/bcp and if possibly while reading data.
>
> We need to support binary bindings of character data. We lost that
> feature when we implemented iconv throughout.
>

well... this point it's too sum up... There are a bit of issues on this
- all columns data must be packaged before calling libTDS function. This it's
quite complicated and it's one of the reasons of rpc/dynamic sql problems in
dblib/ctlib. ODBC works but I don't like the extra work
- Bill use different code for bulk copy... bulk it's just another type of
insert so I don't see much point in using different code and structures
- Steve Kirkendall too used different code
- in ODBC there is a way to stop receiving/sending a row and restart later
(to accomodate space for large text/binary or similar)

There are many solution/optimization/changes that we can combine to relax
these difficulties. For example thinking about inserting (bulk, rpc, dynamic
call) we call call a libTDS function to start sending data and then call
different functions to insert a parameter/column at a time. Or we can provide
a way to libTDS to grab data directly from binded data (calling for example a
function that convert data for use or similar). Or a mix of the two (libTDS
stop when it don't know who to convert parameters and so higher API can do
the job...).

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page