Persistent Connection Question WAS: SELECT LAST_INSERT_ID() keeps

Rizyak wrote: 

This provokes a question I have been pondering for quite some time but
am unsure of how to test for an answer.

I know that this wouldn't be an issue with a regular connection but
using persistent connection suppose I have script.php and there are 2
instances running.

If I do an INSERT followed by mysql_insert_id() in instance1, but
between those 2 statments instance2 does an INSERT, would this introduce
a kind of race condition where instance1 would get the insert id of
instance2?

And the same thing with mysql_select_db(). If instance1 selects
databaseA, and instance2 runs a SELECT statement thinking it is using
databaseB wouldn't that cause an error?

TIA,
Me

Andy Hassall wrote:
>
>  I didn't think persistent connections were multiplexed; I thought they we
re
> allocated to a request for the request's lifetime then released back into 
the
> persistent connection pool. But looking at the source code I can't spot it
> doing this - so possibly.
>

But from what I understand persistent connections are allocated by
host/user/pass, so assuming that the script only uses 1 host/user/pass
combination wouldn't there only be 1 connection?

Or is that the answer... if the script is initiated again and the 1
resource is being used by instance1 it will create another connection,
resulting 2 persistanct resources, in which case they would be seperate
connections and would not suffer from this kind of race condition. That
would make sense.

Andy Hassall wrote:
> On Sat, 16 Apr 2005 12:34:09 -0600, Dumbass <blah@hotmail.com> wrote:
>
> 
>
>
>  Yes, that's exactly the behaviour I was trying to say that I expected - b
ut I
> couldn't see any evidence of it checking whether the matching persistent
> connection was currently in use before letting the current script use it.
>
>
>  Ah - I've just realised why this is fine. There will only be one instance
 of
> PHP running at a given time - per apache worker process. The persistent
> connection pool is itself per worker process, and so there is no way two
> concurrent PHP instances can share the connection, since they'll be on
> different processes.
>
>  I assume that for multi-threaded servers rather than multi-process server
s
> (i.e. IIS or apache on Windows), the connection pool is thread-local - if 
so,
> then again it's safe.
>

That makes sense. I didn't think that the persistent resource list was
per process. I assumed they used shared memory or something. So can we
conclude from this that using a persistent connection with the cli or
cgi SAPI's is pointless? Even if you go thru apache/cgi the cgi process
is a seperate process that will end with the request, destroying the
resource list.