[Dbix-class] DBIx::Safe. DBI wrapper.

Oleg Pronin syber.rus at gmail.com
Wed May 9 23:16:52 GMT 2007


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 =3D 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 =3D 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 <dbix-class at trout.me.uk>:
>
> 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/D=
BIx/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/dbix-class@lists.rawmode.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20070510/9a6=
287b3/attachment.htm


More information about the Dbix-class mailing list