Greeting! I looked at the Storage::DBI's new features in the current branch
related to database connection losses troubles.
There are still caveats there:
1) There are still race conditions
Look at these strings of code (in sub _execute):
$rv = eval { ..... }
$self->throw_exception("Error executing '$sql': ".($@ || $sth->errstr)) if
$self->connected;
$self->_populate_dbh;
Image the SQL syntax (or whatever) error happened in
$rv = eval { ..... };
# and suddenly right here connection to database has been lost
# and the following code will not throw exception because database is not
connected:
$self->throw_exception("Error executing '$sql': ".($@ || $sth->errstr)) if
$self->connected;
This code will restart incorrect query again after it reconnects!
2) Transactions.
a)
in txn_do:
if txn_begin (line 561) fails (not because of disconnection)
then current code will do txn_rollback (line 578) which will always
fail.
b) Similar to "1)" :
Imagine that "$coderef->(@_)" (lines 563, 566) or txn_commit fails
(ordinary SQL error).
And at the next moment connection to database was lost.
Perl will not go through "if" at line 577. Incorrect transaction will
be re-executed.
c) If lost connection while txn_rollback - then rollback is not failed
(just need to ignore, because database will do rollback by itself).
3) This code will try to re-execute statements only once (immediately)!
Administrators or developers will have no chance to restart database server
without having troubles in applications running.
4) Perfomance losses in txn_do, dbh_do etc because of permanent executing
code related to connection losses protection.
5) ::Storage always sets RaiseError to 1 and this is not good. Somebody
might want sql error not to cause exceptions. If ::Storage doesn't set
RaiseError then all protection code will not work.
6) $dbh->prepare is not protected (always cause exception in case of any
error). Some databases can store prepared statements at server-side.
Any non-100% solution is not a solution when working with database.
DBIx::Safe solves all of this problems (this module is not yet released).
So how could i put it to your svn if you dont mind.
2007/5/9, Matt S Trout <[EMAIL PROTECTED]>:
On Wed, May 09, 2007 at 10:49:09PM +0400, Oleg Pronin wrote:
> To matt s trout:
>
> As far as I can see the code related to DB disconnections problem is in
sub
> _execute at ::Storage ?
> am I right?
http://dev.catalyst.perl.org/repos/bast/branches/DBIx-Class-current/lib/DBIx/Class/Storage/DBI.pm
Primarily in there - the RETRY logic is the key part.
--
Matt S Trout Need help with your Catalyst or DBIx::Class
project?
Technical Director Want a managed development or deployment platform?
Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a
quote
http://chainsawblues.vox.com/
http://www.shadowcatsystems.co.uk/
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive:
http://www.mail-archive.com/[email protected]/
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/
