perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Perrin Harkins" <per...@elem.com>
Subject Re: SQLite and multiple process behavior
Date Mon, 18 Jun 2007 19:42:28 GMT
On 6/18/07, Jeff Nokes <jeff_nokes@yahoo.com> wrote:
> [Jeff]  When I'm testing against my dev server, I'm the only one playing in that sandbox,
> so I'm just doing single requests, there is definitely no locking or concurrency issues
> happening.

I was mostly thinking of the kind of issues that more sophisticated
databases sometimes have with isolation levels.  For example, when
using the default isolation level with MySQL InnoDB tables, a reader
can't see data committed by other processes if the reader is in a
transaction.

> When I had multiple shells open, and my web app all connected to the same SQLite db file,
> I saw the same behavior as before, where the shells would show something different than
the
> web app.  But, after some amount of time, and some number of writes to the db, all of
the shells
> and the web app were in-sync.  So, it looks as though if I wait long enough, all processes
on the
> same dev box would be in-sync, with the web app, and all is well.

Just a hunch: if you add a commit to the beginning of your web code,
does that change anything?

> [Jeff]  I'm doing very vanilla stuff; I doubt example code would show anything.

I was mostly thinking of the typical perl scoping issues, like
accidental closures:

my $x = some_database_method();

sub foo {
    print $x;
}

This code will never pick up changes from the database.

> It's almost like the OS is keeping two distinct
> versions of this file, when there is only one on the drive.

It may well be holding onto the old file, even though you don't see it
when you list the directory.  Open handles to an unlinked file still
work.

> At least I know when I do everything from the web interface, it seems to work
> great across all apache children.

That's why I think that either doing a commit at the beginning of the
request, or reopening your DBI connection, will fix the problem.

- Perrin

Mime
View raw message