Re: libct ct_connect thread_safe

Mitch Freed <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
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<[email protected]>  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
> [email protected]
> 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 [email protected], and destroy all copies of this message and any attachments without reading or disclosing them.  Thank you.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.