[eluser]drewbee[/eluser]
Yes -- It is based on the last insert id of the last query ran of the current connection to the database. The only time I could potentially forsee issues is if you close the query connection, then open a new one. Not sure why you would do this though.
[eluser]Phil Sturgeon[/eluser]
What if one person manages to insert a query in the 0.0034 seconds between the insert and the call of the insert_id()? Hopefully we can presume that process time is the same for every request and therefore its impossible... right?
[eluser]fouadami[/eluser]
Well that's what I mean, while MySQL doesn't lock the table and both users are using the same user name to connect to the database, if we assume the clock time of the CPU and the OS queue and the lack of transaction, is it possible to get the wrong result when we call db->insert_id()?
[eluser]drewbee[/eluser]
I am sorry. I do not think I am explaining this good enough.
The connection opened up is relative to the current user. Each user holds on there own personal connection to the database. So when insert_id() is returned, it is relative to that user only. User1 cannot get User2's insert_id() without bridging connections (which is unlikely). You could be more worried if you use mysql_pconnect, where users share connections though. I don't know how it affects this part of things.
[eluser]Michael Wales[/eluser]
Technically, yes it's possible. Realistically, probably not.
I definitely wouldn't go about closing connections as soon as you are done returning results though. If you pconnect disabled the connection will be automatically closed as soon as script execution has been completed.
[eluser]fouadami[/eluser]
I was just a little bit worry about persistent connection excess in open connections, but I think I'd better choose pconnection... ;-)