List:MySQL++« Previous MessageNext Message »
From:Julien Chavanton Date:September 20 2006 6:23pm
Subject:RE: Connection sharing vs lost of query per connections
View as plain text  
I am confused because it seem "sharing" the connection between one
hundred threads does not seem to produce any "sync error" as long as
each thread as it's own "MYSQL_RES *res_ptr" they can simultaneously use
the connection, if this is true, I found this solution perfect since I
only want to minimize the amount of connections I do not want to
minimise the amount of MYSQL_RES structure in memory.

I have made lots of stress test with 100 threads sharing one connection
and there was no problem.

Maybe what the manual mean was that threads can not share the same
MYSQL_RES structure without using mutex or maybe I am really lucky while
doing my stress tests?




-----Original Message-----
From: Julien Chavanton 
Sent: September 20, 2006 10:50 AM
To: Julien Chavanton; 'plusplus@stripped'
Subject: RE: Connection sharing vs lost of query per connections

I understand the only work around is to make "pooling" meaning the
software will dynamically create and share a certain amount of
connections amongst the threads as it will be required to avoid (mutex
lock) an to minimize the number of connections.

Since I have since it is a performance issue to have too many
connections.

Are my presumptions correct or do I miss something?



-----Original Message-----
From: Julien Chavanton 
Sent: September 20, 2006 10:28 AM
To: 'plusplus@stripped'
Subject: RE: Connection sharing vs lost of query per connections


I was thinking the Mysql++ api was thread safe because the database
system is using lock's himself and because of other opionion I have read
about connection pooling.

Reading the documentation it is written that when sharing a connection
between threads we have to lock the connection between
Mysql_query() and mysql_store_result() witch mean we have to wait after
the full query completion and data transfer, it is then clear that
sharing connection is not interesting since one slow query could
interfere with another quick query (that may normally not be affected by
database locks).

I have to conclude that Mysql++ is not efficient with threading while
sharing connection, I hope I misunderstand something?

Or is there another way around?



-----Original Message-----
From: Warren Young [mailto:mysqlpp@stripped] 
Sent: September 19, 2006 11:59 AM
To: MySQL++ Mailing List
Subject: Re: Connection sharing vs lost of query per connections

Julien Chavanton wrote:
> I think my problem was
> mysql_ping() after reading the description again I found that we must
> use this only when there was a significant idle period and not every
> query like I was doing.

Yes.  While a ping is the least expensive round-trip call you can have 
to the database, it's still expensive in terms of local CPU time.

> I guess the normal behaviour is to wait after an error and then
> reconnect if possible?

There's a MySQL connection option to make the library try to reconnect 
automatically.  This was covered just days ago.  Search the list.

You should still write your code with an awareness that a connection 
could fail, however.  Networks break, servers die.

-- 
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?unsub=1

Thread
Connection sharing vs lost of query per connectionsJulien Chavanton18 Sep
RE: Connection sharing vs lost of query per connectionsJulien Chavanton18 Sep
  • Re: Connection sharing vs lost of query per connectionsWarren Young19 Sep
RE: Connection sharing vs lost of query per connectionsJulien Chavanton20 Sep
  • Re: Connection sharing vs lost of query per connectionsWarren Young21 Sep
RE: Connection sharing vs lost of query per connectionsJulien Chavanton20 Sep
RE: Connection sharing vs lost of query per connectionsJulien Chavanton20 Sep
  • RE: Connection sharing vs lost of query per connectionsMatt Dargavel21 Sep