List:MySQL and Perl« Previous MessageNext Message »
From:Jochen Wiedmann Date:June 8 2001 10:18pm
Subject:Re: Maintaining State/Cached Connections
View as plain text  
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
Thread
DBD::mysql ProblemsJason Allocco6 Jun
  • Re: DBD::mysql ProblemsJeremy Zawodny6 Jun
  • Re: DBD::mysql Problemsed phillips6 Jun
  • Maintaining State/Cached ConnectionsDodger6 Jun
    • Re: Maintaining State/Cached ConnectionsTodd Finney7 Jun
    • Re: Maintaining State/Cached ConnectionsDave Rolsky8 Jun
      • Re: Maintaining State/Cached ConnectionsJochen Wiedmann8 Jun
      • Re: Maintaining State/Cached ConnectionsTodd Finney8 Jun
    • Re: Maintaining State/Cached ConnectionsJochen Wiedmann8 Jun
      • Re: Maintaining State/Cached ConnectionsTodd Finney8 Jun
        • Re: Maintaining State/Cached ConnectionsJochen Wiedmann9 Jun
          • Re: Maintaining State/Cached ConnectionsStas Bekman9 Jun
            • Re: Maintaining State/Cached ConnectionsJochen Wiedmann10 Jun
              • Re: Maintaining State/Cached ConnectionsStas Bekman10 Jun