On Aug 6, 3:20 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> What you have described shouldn't require any particularly special
> handling. I have code in production that does exactly the same thing -
> a daemonized process that responds to requests on a port, does some
> processing, and saves the result to the database. You shouldn't need
> to do anything exotic with connection or transaction handling.
>
> As for the cause of your problem - my immediate thought is that your
> processing+save steps aren't as simple as you think they are. In
> particular, if you're getting:
>
> > InternalError: current transaction is aborted, commands ignored
> > until end of transaction block
>
> then something is going wrong in your code - somewhere, an error isn't
> being handled properly. However, without specifics, it's hard to
> narrow down the problem. Time to crack open the debugger to see
> exactly what sequence of events is leading to errors.
Except that I can't seem to reproduce the problem reliably. It's an
error I only see in production, none of my test cases activate it and
even when I run it within a test environment, the problem has yet to
crop up.
> The only other alarm bell that is ringing for me is that your errors
> are related to SET ISOLATION LEVEL requests, and you're using
> Postgres.
There are two things odd about these errors. The first is that db
backed for postgresql appears to set an isolation level on every new
database connection, immediately after opening the connection (in the
django.db.backends.postgresql.base.DatabaseWrapper._cursor() method).
The second is that the errors are being triggered by a simple get()
on queryset.
File "mycode.py", line 165, in task
job = models.Job.objects.get(id=int(job.body))
File ".../lib/python2.5/site-packages/django/db/models/manager.py",
line 93, in get
return self.get_query_set().get(*args, **kwargs)
File ".../lib/python2.5/site-packages/django/db/models/query.py",
line 304, in get
num = len(clone)
File ".../lib/python2.5/site-packages/django/db/models/query.py",
line 160, in __len__
self._result_cache = list(self.iterator())
File ".../lib/python2.5/site-packages/django/db/models/query.py",
line 275, in iterator
for row in self.query.results_iter():
File ".../lib/python2.5/site-packages/django/db/models/sql/
query.py", line 206, in results_iter
for rows in self.execute_sql(MULTI):
File ".../lib/python2.5/site-packages/django/db/models/sql/
query.py", line 1734, in execute_sql
cursor.execute(sql, params)
File ".../lib/python2.5/site-packages/django/db/backends/util.py",
line 19, in execute
return self.cursor.execute(sql, params)
InternalError: SET TRANSACTION ISOLATION LEVEL must be called before
any query
This particular daemon does a lot of reading before it ever (if ever)
actually does a write. Looking into how the ORM is set up by default,
it appears a transaction is opened up and stays open until a save()
occurs. If a save() doesn't occur, will I hit a limit on my
transaction size?
> Out of interest - are you using the autocommit feature added
> to Django in v1.1?
Nope, I'm currently using Django v1.0.2 (likely upgrading to 1.0.3
rsn).
-- William
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
