On Thu, Apr 26, 2007 at 10:29:23PM +0400, Oleg Pronin wrote:
> I'm creating a DBI wrapper (it will be called DBIx::Safe) that handles all
> disconnections transparently.
> If there is no transaction this module gives you 100% guarantee that your
> query will be executed without disconnection errors
$sth->errstr() =~ m/gone away/i
this is the first method that i used. (per database string checking)
and this is i'm going away from.
2007/4/28, Peter Edwards <[EMAIL PROTECTED]>:
I've seen this problem under Red Hat Enterprise Linux 4 and Mysql 3.23 and
suspect it was down to incorrect confi
I've seen this problem under Red Hat Enterprise Linux 4 and Mysql 3.23 and
suspect it was down to incorrect configuration of full/half duplex on the
Network Interface Card against the router, possibly combined with a Linux
Ethernet driver bug. Some useful pointers here
http://dev.mysql.com/doc/refm
> That /is/ what we are talking about - unless MySQL cannot
> tell you that the database connection has evaporated while in
> transaction context.
$dbh can tell you. while in transaction $dbh->{AutoCommit} is off.
___
List: Catalyst@lists.rawmode.org
Oleg Pronin wrote:
> If you don't need transaction you don't use it. This is not we talking
> about. To use transaction or not in every case is a high-level logic
> decision
I disagree. That /is/ what we are talking about - unless MySQL cannot
tell you that the database connection has evaporated wh
Oleg Pronin wrote:
> If you don't need transaction you don't use it. This is not we talking
> about. To use transaction or not in every case is a high-level logic
> decision
I disagree. That /is/ what we are talking about - unless MySQL cannot
tell you that the database connection has evaporated wh
If you don't need transaction you don't use it. This is not we talking
about. To use transaction or not in every case is a high-level logic
decision
2007/4/27, Jeff Chimene <[EMAIL PROTECTED]>:
Oleg Pronin wrote:
> One can say that it is a very rare situation. I can tell you that in
> productio
Oleg Pronin wrote:
> One can say that it is a very rare situation. I can tell you that in
> production environment (about 1.000.000 hits per day) it happens every
> day several times. Some users just see an error, some lost their data.
> This is just not always visible to you.
The OP may find a req
I give more details:
1) simple
$dbh->ping; #ok
#database connection lost here
$resultset->search(..); # ooops.
2) for example, inside DBIC
$dbh->ping; #ok
$sth = $dbh->prepare(..); #ok
$dbh->ping; #ok
#database connection lost;
$sth->execute(...); #oops
with this module you can just do
$dbh->pr
One can say that it is a very rare situation. I can tell you that in
production environment (about 1.000.000 hits per day) it happens every day
several times. Some users just see an error, some lost their data. This is
just not always visible to you.
2007/4/27, Oleg Pronin <[EMAIL PROTECTED]>:
No. SQL query may produce various errors. Imagine that you got an ordinary
SQL syntax error (you dont know that) and then you want to check $dbh->ping
in order to know was there disconnect or not. But between this short moments
database connection was lost. And you will think that it was disconnec
"Oleg Pronin" <[EMAIL PROTECTED]> wrote on 04/26/2007 01:29:23 PM:
> Hi all!
>
> Unfortunately, Catalyst::Model::DBI and similar modules are too
> simple to avoid some more rare situations.
> For example, what if $dbh->prepare result is fine but before you
> call $dbh->execute the database w
Hi all!
Unfortunately, Catalyst::Model::DBI and similar modules are too simple to
avoid some more rare situations.
For example, what if $dbh->prepare result is fine but before you call
$dbh->execute the database will be "gone away"?
I'm creating a DBI wrapper (it will be called DBIx::Safe) that
Hi all,
It works again now. I looked at Catalyst::Model::DBI and noticed it
was using $self->NEXT::new( @_ ) so I did the same thing with my
Model and it seemed to work without a hitch!
Well, thanks all for you help.
Regards,
Adeola.
On 19 Apr 2007, at 14:38, Adeola Awoyemi wrote:
Thank
On 19 Apr 2007, at 14:31, Jon wrote:
On Thu, 2007-04-19 at 13:54 +0100, Adeola Awoyemi wrote:
Hi all,
I have problem that when I run my app via fastcgi I get an error
where one of my models can't connect to the database with the message
"MySQL server has gone away". When I start it using 'sc
On Thu, 2007-04-19 at 13:54 +0100, Adeola Awoyemi wrote:
> Hi all,
>
> I have problem that when I run my app via fastcgi I get an error
> where one of my models can't connect to the database with the message
> "MySQL server has gone away". When I start it using 'script/
> myapp_server.pl' it
Adeola Awoyemi scribbled on 4/19/07 7:54 AM:
Hi all,
I have problem that when I run my app via fastcgi I get an error where
one of my models can't connect to the database with the message "MySQL
server has gone away". When I start it using 'script/myapp_server.pl' it
works fine.
Has anyon
On Thu, Apr 19, 2007 at 01:54:52PM +0100, Adeola Awoyemi wrote:
> Hi all,
>
> I have problem that when I run my app via fastcgi I get an error
> where one of my models can't connect to the database with the message
> "MySQL server has gone away". When I start it using 'script/
> myapp_server.
Hi all,
I have problem that when I run my app via fastcgi I get an error
where one of my models can't connect to the database with the message
"MySQL server has gone away". When I start it using 'script/
myapp_server.pl' it works fine.
Has anyone come across this before? Any hints to fixin
19 matches
Mail list logo
