On Mon, 2004-05-17 at 18:55, Dave Boodman wrote:
> OK, here's some small(er) code I that repeats the problem.
Dave, this is really too much code, at least for me. It also refers to
lots more code that isn't shown here. If you go through the process of
reducing all of this to a small and complete example that illustrates
the bug, you will probably find the solution in the process.
> # process updates
> foreach my $obj (@toupdate) {
> $self->model->log('info', "updating obj:");
> $self->model->log_dumper('info', $obj);
> eval { $obj->update };
> if ($@) {
> $self->model->log('info', 'update failed, rolling back');
> foreach my $o (@created) { $o->dbi_rollback; }
> $self->context->throw( 'update', $@ );
> } else {
> push @created, $obj;
> }
> }
>
> # if we made it this far, commit everything
> foreach my $obj (@toupdate) { $obj->dbi_commit; }
> foreach my $obj (@created) { $obj->dbi_commit; }
Those dbi_rollback and dbi_commit calls don't do what you're thinking
they do. Transactions are database-wide, so the first rollback or
commit affects everything and anything after that is just wasted.
> You can see that when I try to retrieve the new customer, the # of
> hashes (the number of items the customer has) returned differs
> depending on the PID of the child. (All children should be returning
> 2)
If you run httpd with the -X flag, you may be able to come up with a
series of steps to reproduce this error reliably. That will allow you
to debug it using normal methods.
- Perrin
--
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
