By regular do you mean with each invocation? Cause I regularly see the same children not return the newly-inserted data, while (most) others regularly return it fine. In -X, the single process always returns the right data.
I've just run the update with the following code:
package Plugin::TESTCustomers;
use base qw( Template::Plugin );
use strict;
sub new {
} # end new
sub model {
}
sub context {
}
sub update {
my $self = shift;
my %tmp;
$tmp{'cid'} = 'col00179';
$tmp{'start_date'} = '2004-05-18';
$tmp{'machine'} = 'test';
my $sys;
$self->model->log('info', "inserting new system");
eval { $sys = Lib::Systems->create( \%tmp ) };
if ($@) { $self->model->log('info', "create error"); }
eval { $sys->dbi_commit };
if ($@) { $self->model->log('debug', 'commit failed'); }
return;
}
1;
And I get the same results:
66218 2004-05-18/14:32:53 64.186.244.42 debug dave Plugin::Systems 33 retrieve(col00179) returning 3 hashes
66247 2004-05-18/14:32:53 64.186.244.42 debug dave Plugin::Systems 33 retrieve(col00179) returning 1 hashes
66267 2004-05-18/14:32:54 64.186.244.42 debug dave Plugin::Systems 33 retrieve(col00179) returning 2 hashes
66217 2004-05-18/14:32:54 64.186.244.42 debug dave Plugin::Systems 33 retrieve(col00179) returning 1 hashes
(where each call/reload should be retrieving 3 hashes)
Is it possible mysql children are feeding httpd children bogus data?
-Dave
At 02:03 PM 5/18/2004, Perrin Harkins wrote:
[ Please keep the conversation on the list... ]-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
On Tue, 2004-05-18 at 16:23, Dave Boodman wrote:
> ok, thanks for the tips on the commit/rollback. so, i can call it on any
> old obj or do i have to (can i) create a special/new obj just to do the
> commit/rollback.
You can call it on any object, or as a class method.
> i assume it knows what to roll back based on the updates
> done for the current invocation of the script?
It rolls back everything done on the current database connection since
the last time you committed.
> also, i know about running -x, i just assumed that if it's committing
> somewhere, than in x the problem just wouldn't show up at all.
No, that's not correct. If you are seeing this problem regularly, then
there is some sequence of actions which will cause it. The only chance
you have of coming up with a set of steps to reproduce the problem is to
run with -X. Otherwise, you get a different child process every time
and you have no idea what series of steps caused the issue.
The only kind of problem that will not be reproducible under -X is when
you have something that comes directly from the interaction of threads
or processes. That doesn't sound like what you're seeing here.
- Perrin
