Skip to Content.
Sympa Menu

freetds - Re: [freetds] libct ct_connect thread_safe

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Mitch Freed <mfreed AT nitrosecurity.com>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] libct ct_connect thread_safe
  • Date: Thu, 15 Dec 2011 08:09:58 -0700

I my case I have n servers that I am connecting to with 1 connection per server.

- Mitch

On 12/14/2011 10:16 PM, James K. Lowden wrote:
On Wed, 14 Dec 2011 16:18:23 -0700
Mitch Freed<mfreed AT nitrosecurity.com> wrote:

Is ct_connect (libct) not thread-safe?
...
I have seen the FAQ indicating that the threads cannot share a
CS_CONNECTION, which they do not in my case.

I don't understand those two statements. ct_connect() takes a
CS_CONNECTION* as its first argument. "Cannot share a connection"
means cannot use a single CS_CONNECTION struct in more than one
thread. Calling ct_connect() *is* using that connection.

So, no, I guess you'd have to say ct_connect() is not thread-safe. Not
that it should be, either!

I would be curious to know (from anyone) why you use
more than one thread to interact with a server connection. The server
is I/O bound by the network. The client is certainly faster or, if not,
two threads won't be faster than one.

The only answer I know of is when the client is some kind of
multithreaded something (a webserver, say) sharing a smaller number
of database connections.

But why? In the vast majority of cases, that is a false economy: the
overhead of making connections and of the server supporting 1:1
connections/thread is negligible. How do I know? Because the vast
majority of websites are small and slow.

Unless you're measuring response times in milliseconds, what
difference can the time it takes to connect to the server possibly
make? As soon as you accept the connect-time overhead, you know that
every connection is needed, and that therefore if the database server
can't support those connections, you need one that can. (Probably you
need more RAM.)

Maybe you're reading this, saying to yourself that you can't wait for
the time it takes to log in. If so, I'd like to understand why not.
Really. I know sites like Google have scale and throughput issues that
require sophistication. But I also know most sites aren't a big as
Google.

My test database server is ~300 ms away, round trip, says ping.
time(1) reports I can ping it 100 times in ~50 seconds (using a loop in
bash). That same loop lets me log in 100 times in ~60 seconds using
tsql. That puts each ping, allowing bash overhead, etc., at 500 ms,
and each login at 600 ms, or 100 ms to log in. That's consistent with
my experience at work; I've never used a server where login times were
significant. Or a webserver with latency in that neighborhood,
either, for that matter.

What am I overlooking? I'd bet 9 in 10 webservers not using 1:1
database connections are wasting time engineering something that
doesn't need engineering. Would someone please tell Mitt Romney? I
hear tell he's a betting man.

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
.

This e-mail message and any attachments contain information that is
confidential and may be privileged. If the reader of this e-mail is not the
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you
have received this communication in error, please immediately notify us by
replying to this message or by sending an email to
postmaster AT nitrosecurity.com, and destroy all copies of this message and any
attachments without reading or disclosing them. Thank you.





Archive powered by MHonArc 2.6.24.

Top of Page