Quoting Todd Finney <tfinney@stripped>:
> I'm not sure if I understand you. Are you saying that this:
>
> http://perl.apache.org/guide/performance.html#Preopening_Connections_at_the_Ch
>
> is false when talking about mysql?
I have just read the page: The answer is definitely yes.
What Stas says is right when talking about persistent connections:
Using Apache::DBI is definitely recommended. (It won't make that
much a difference, because creating a new connection with MySQL
is comparatively lightweight.)
He's definitely wrong when referring to "preopening connections".
This can definitely be causing serious trouble, unless you ensure
proper serialization. Let me illustrate this with a simple example.
As you know, MySQL is now supporting transactions. (We do not
need transactions to construct a problem, this example is just
comparatively simple.) Let's assume we have two processes both
using the same connection and watch the following steps:
a) Client 1 starts a transaction
b) Client 2 starts a transaction
c) Client 1 inserts a row
d) Client 2 inserts a row
e) Client 1 does a rollback
f) Client 2 does a commit
The result: No rows have been inserted, because the rollback
removes both rows.
For statement handles, this is not completely true. With the
*current* implementation you may prepare statement handles at
the web servers startup. However, this may change with any
new version of the MySQL client library. It cannot be recommended.
Note: Using Apache::DBI in your scripts is safe, likewise for
the prepare_cached method of DBI. It is even safe to load
Apache::DBI at startup. However, any handles created by the
Apache parent process must not be shared by the child processes.
Hope this clarifies the case.
Jochen
