Re: mod_perl sql result cache

[grantm]

That really depends on your application/framework. mod_perl puts a persistent Perl interpreter inside each Apache process, so the values stored in global variables (or file scoped lexicals, or indeed anything that's still referenced) at the end of one request will still be there at the start of the next.

The problem with this raw mechanism is that the persistent/cached values exist separately in each Apache child process. Which means 1) you get multiple copies and 2) there's no way to invalidate a cached item across all processes.

It's usually better to use something like memcache to manage persistent cache values. It avoids the multiple copies issue and provides a central place to invalidate cached items.

So in summary, I'm afraid you'll have to dive into the code for your app to find out how it manages cached values.

[jbenezech]

The only global variable I'm using is AUTOLOAD. I'm coding in OO style and using inheritance. I'm using AUTOLOAD for more flexibility in my object structures.

package Entities::Entity;

our $AUTOLOAD;
use constant UNDEF_VALUE => '##UNDEF_VALUE##';

sub new() {
    my ($class) = @_;
    my $self = {
    };
    bless $self, $class;
    return $self;
}

sub AUTOLOAD {
    my ($self, $val) = @_;
    
    my $type = ref($self) or croak "$self is not an object";

    my $name = $AUTOLOAD;
    $name =~ s/.*://;   # strip fully-qualified portion
    if (defined($val)) {
        if ($val eq UNDEF_VALUE) {
            $self->{$name} = undef;
        } else {
            return $self->{$name} = $val;
        }
    } else {
        my $val = $self->{$name};
        $self->{$name} = undef unless (defined($val));
        if (ref($val) eq "HASH") {
            return \%$val;
        }
        if (ref($val) eq "ARRAY") {
            return \@$val;
        }
        return $val;
    }
}

package Customer::Entities::CustomerInvoice;

use base qw(Entities::Entity);

sub new {
    my ($class) = @_;

    my $self = $class->SUPER::new();
    return $self;
}

On the other hand, everytime a new request comes in, new objects are created. If the member's values were cached, nothing would work properly I guess. Also, my debug messages show that each object is different.

On the database end, the only package level global variable is a hash holding the database handles. I do not do any explicit caching. There is also no cached queries in mysql.

I was suspecting apache/modperl to do some transparent query result caching for long running queries. Could it be the case ? (for info, I'm running ActivePerl 5.10, Apache 2.2, XP SP2).

I thought I would try to look into apache's memory and see what objects are still in cache after a request but I cannot find a repository for the B-Size module. Any idea where to find this ? (probably different topic)

Thanks

[jbenezech]

I've found that post which seems to bring some sense: http://stackoverflow.com/questions/3952242/dbi-database-handle-with-autocommit-set-to-0-not-returning-proper-data-with-selec

I'm wondering if the persistent nature of modperl could lead to the following sequence:
- Autocommit is off and using InnoDB
- 1 session connects and reads data, no rollback or commit
- 1 session connects and writes data, commit
- The first session reads again, gets the same db handle for which the transaction is still ongoing and therefore retrieves cached data