Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #11363 > unrolled thread
| Started by | John Gordon <gordon@panix.com> |
|---|---|
| First post | 2011-08-14 02:20 +0000 |
| Last post | 2011-08-16 00:10 +0000 |
| Articles | 4 — 2 participants |
Back to article view | Back to comp.lang.python
Data issues with Django and Apache John Gordon <gordon@panix.com> - 2011-08-14 02:20 +0000
Re: Data issues with Django and Apache Daniel Roseman <daniel@roseman.org.uk> - 2011-08-14 11:12 -0700
Re: Data issues with Django and Apache John Gordon <gordon@panix.com> - 2011-08-14 23:43 +0000
Re: Data issues with Django and Apache John Gordon <gordon@panix.com> - 2011-08-16 00:10 +0000
| From | John Gordon <gordon@panix.com> |
|---|---|
| Date | 2011-08-14 02:20 +0000 |
| Subject | Data issues with Django and Apache |
| Message-ID | <j27bde$dlr$1@reader1.panix.com> |
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"
[toc] | [next] | [standalone]
| From | Daniel Roseman <daniel@roseman.org.uk> |
|---|---|
| Date | 2011-08-14 11:12 -0700 |
| Message-ID | <09dcb0e2-a8ae-4dfd-9e27-94b32188e4e1@glegroupsg2000goo.googlegroups.com> |
| In reply to | #11363 |
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. > > 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 > 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 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. -- DR.
[toc] | [prev] | [next] | [standalone]
| From | John Gordon <gordon@panix.com> |
|---|---|
| Date | 2011-08-14 23:43 +0000 |
| Message-ID | <j29mib$310$1@reader1.panix.com> |
| In reply to | #11407 |
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"
[toc] | [prev] | [next] | [standalone]
| From | John Gordon <gordon@panix.com> |
|---|---|
| Date | 2011-08-16 00:10 +0000 |
| Message-ID | <j2cchc$167$1@reader1.panix.com> |
| In reply to | #11363 |
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"
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.python
csiph-web