Data issues with Django and Apache

[John Gordon]

I'm devleoping a website using the Django framework along with Apache,
and I'm seeing some odd data issues.

During the course of navigating through the website content, a user
will cause the creation of some data records with a limited lifespan.
These data records have a create_dt field which is automatically set to
the time that they were created, and an expire_dt field which is equal
to create_dt plus ten minutes.

The problem is that I get conflicting results as to whether these temporary
records have reached their expiration date, depending if I search for them
via an Apache web call or if I do the search locally from a python shell.

And to make it weirder, the conflicts go away if I stop and restart the
Apache server, although any new records created after this point will still
exhibit the issue.

Are there any known "gotchas" when using Django with Apache? It almost
seems like Apache is maintaining its own persistent session or something,
and restarting Apache causes the session to be flushed.

 

[Daniel Roseman]

I'm devleoping a website using the Django framework along with Apache,
and I'm seeing some odd data issues.

During the course of navigating through the website content, a user
will cause the creation of some data records with a limited lifespan.
These data records have a create_dt field which is automatically set to
the time that they were created, and an expire_dt field which is equal
to create_dt plus ten minutes.

The problem is that I get conflicting results as to whether these temporary
records have reached their expiration date, depending if I search for them
via an Apache web call or if I do the search locally from a python shell.

And to make it weirder, the conflicts go away if I stop and restart the
Apache server, although any new records created after this point will still
exhibit the issue.

Are there any known "gotchas" when using Django with Apache? It almost
seems like Apache is maintaining its own persistent session or something,
and restarting Apache causes the session to be flushed.

Well, without seeing any code, it's hard to tell. And Apache (with mod_wsgi) is the recommended deployment method, so you can't really say there are gotchas.

My guess is that you have not understood that server processes - and this is true on the dev server as well as on Apache - are not the same as requests. That is, server processes are long-lasting, and one process may end up serving tens or hundreds of requests before being recycled. So, if you have any code that runs at process startup - such as default values in class definitions or at module level - it will persist for all requests served by that process.

Like I say, though, it would really help if you showed the relevant code.

 

[John Gordon]

Like I say, though, it would really help if you showed the relevant code.

I know. But trimming the code down to where it would be fit for posting
is a moderately big job and I'm somewhat pressed for time. I was just
hoping that someone would recognize the problem from the few symptoms I
gave.

 

[John Gordon]

The problem is that I get conflicting results as to whether these temporary
records have reached their expiration date, depending if I search for them
via an Apache web call or if I do the search locally from a python shell.

And to make it weirder, the conflicts go away if I stop and restart the
Apache server, although any new records created after this point will still
exhibit the issue.

The problem turned out to be a class variable that contained a time filter
with the "current" time.

But since it was a class variable, it was only evaluated once upon import
and its idea of "now" was forever frozen at that moment, so it always
compared as being less than any of the lock records that were passed in.

I changed it to be a class method that constructs and returns a new time
filter whenever it is called.

Thanks for everyone's help!