in reply to Re: SQLite with mod_perl
in thread SQLite with mod_perl

According to this question in the SQLite faq, "Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however." If you aren't using the AutoCommit mode and you have an uncommitted transaction (which would lock the database), that may be your problem, so either commit soon after making an update or set AutoCommit on.

Alternatively, you may have kept the same database handle open across a fork call, which this mentions as the source of problems, so don't do that either.

Replies are listed 'Best First'.
Re^3: SQLite with mod_perl
by punkish (Priest) on Oct 09, 2010 at 02:21 UTC
    Alternatively, you may have kept the same database handle open across a fork call, which this mentions as the source of problems, so don't do that either.
    So, this may partly be just my ignorance. I am assuming that Apache2 is the forking server here. After all, it spawns little children to manage the web queries.

    I am not sure how things work under a mod_perl (or even a fastcgi) kind of persistent perl environment under Apache2. I am assuming that my entire application is compiled and loaded when the server starts. At this point, a db handle is not created. Then, a user queries, which causes a db handle to be created. Since I don't want a new db handle created for subsequent queries by the same user, I reuse the db handle. And, I don't disconnect the db handle, because, if I do, then subsequent queries will fail. How do I ensure that a persistent, unique db handle is created for each user to my web site?

    --

    when small people start casting long shadows, it is time to go to bed