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.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

On Sunday, 14 August 2011 03:20:30 UTC+1, John Gordon  wrote:
> I'm devleoping a website using the Django framework along with Apache,
> and I'm seeing some odd data issues.
>=20
> 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.
>=20
> The problem is that I get conflicting results as to whether these tempora=
ry
> records have reached their expiration date, depending if I search for the=
m
> via an Apache web call or if I do the search locally from a python shell.
>=20
> 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 sti=
ll
> exhibit the issue.
>=20
> 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.
>=20
> --=20
> John Gordon                   A is for Amy, who fell down the stairs
> gor...@panix.com              B is for Basil, assaulted by bears
>                                 -- Edward Gorey, "The Gashlycrumb Tinies"


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 g=
otchas.

My guess is that you have not understood that server processes - and this i=
s true on the dev server as well as on Apache - are not the same as request=
s. That is, server processes are long-lasting, and one process may end up s=
erving 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 def=
initions or at module level - it will persist for all requests served by th=
at process.

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

In <09dcb0e2-a8ae-4dfd-9e27-94b32188e4e1@glegroupsg2000goo.googlegroups.com> Daniel Roseman <daniel@roseman.org.uk> writes:

> 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                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

In <j27bde$dlr$1@reader1.panix.com> John Gordon <gordon@panix.com> writes:

> 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!

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"