note 46913 added to function.mysql-pconnect
| From: | markunderscoreconnollyatacmdotorg at osu1 dot php dot net | Date: | Wed, 27 Oct 2004 17:59:32 +0000 |
| Subject: | note 46913 added to function.mysql-pconnect | ||
| Groups: | php.notes | ||
| Request: | Send a blank email to php-notes+get-79199@lists.php.net to get a copy of this message | ||
I would like to comment on the post from dfischer at qualcomm dot com that proposes spanning
transactions over multiple application invocations, in case someone is bold enough to try it.
I'll assume the table types being used are one of those that support transactions, such as
InnoDB or BerkeleyDB.
First, there is a question of whether this would work at all. To work at all, the transaction
context would have to be preserved across all the invocations of the php code through the web
server. Reading the description of http://www.php.net/manual/en/features.persistent-connections.php
maintaining transaction context would be at best a coincidence. It would be interesting to find out
that this does work on occasion and to understand the ramifications of such behavior. If I happened
to get your connection and my action was a cancel, your updates might be gone.
Second, if such a thing did work (occassionally or always), there would be performance implications
as the underlying database managed transactions that were pretty much open-ended. A few
long-running transactions would likely eat up many resources in a short time and the likelihood of
concurrency conflicts could rise. If the mysql_pconnect behavior is to keep transaction open at the
end of php processing, then it would probably be better to not define transactions when using
mysql_pconnect. And, transactions that were never closed by code (user went out to lunch and got hit
by a bus) could hold resources for quite some time (maybe until after rehab).
So, even if such a scheme COULD work, it is not a good idea. The transaction should be committed or
rolled back at the end of the user request processing. This allows the DBMS to properly manage
resource ultilization and keeps bad things from happening to good data. If mysql_pconnect does not
coordinate well with the transaction component of the database engine to always end a transaction at
the end of processing a request, then mysql_pconnect should never be used where begin transaction is
used.
----
Manual Page -- http://www.php.net/manual/en/function.mysql-pconnect.php
Edit -- http://master.php.net/manage/user-notes.php?action=edit+46913
Delete -- http://master.php.net/manage/user-notes.php?action=delete+46913&report=yes
Reason: bad code -- http://master.php.net/manage/user-notes.php?action=delete+46913&report=yes&reason=bad+code
Reason: spam -- http://master.php.net/manage/user-notes.php?action=delete+46913&report=yes&reason=spam
Reason: useless example -- http://master.php.net/manage/user-notes.php?action=delete+46913&report=yes&reason=useless+example
Reason: contains commercial links -- http://master.php.net/manage/user-notes.php?action=delete+46913&report=yes&reason=contains+commercial+links
Reason: useless note -- http://master.php.net/manage/user-notes.php?action=delete+46913&report=yes&reason=useless+note
Reject -- http://master.php.net/manage/user-notes.php?action=reject+46913&report=yes
Search -- http://master.php.net/manage/user-notes.php