Hi Shai, Thanks for compiling this list ! My answers below.
> First -- the very mention of this topic reminded me of > https://code.djangoproject.com/ticket/9964, which was my pet bug for about > two > years. The point of that bug, though, was to make sure that transactions are > properly closed before (and regardless if) the connection is closed, so while > related, it should be unaffected. If anything, persistent connections will *require* proper transaction termination at the end of each request cycle. > Second -- Tasks out of requests. Core developers participating in this > discussion already have this in mind, Aymeric has commented about it in > https://code.djangoproject.com/ticket/17887, but it was left out of the > discussion on the thread. The suggested changes, AFAICT, modify the behavior > around the end of requests only -- for tasks, nobody closed the connection > before, and nobody is going to do anything different now; so that's not > "something missed" either. Yes, this patch must not affect behavior outside of the request handler. > Third -- different use patterns of multi-db. AFAICT the change treats all > connections as equals, so no new problems should arise, but I can't remove a > gnawing suspicion that some interaction may pop up. In particular, I'm > worried > because not all such patterns are automatically tested; I know my pet pattern > (two aliases for one db, for different transaction behavior -- for logging > into > db, which shouldn't be reverted when the main transaction is rolled back) has > had problems unnoticed by others (see e.g. > https://code.djangoproject.com/ticket/14415). The problem described in that ticket occurred because of the invalid assumption that each connection was to a different database. As far as I can tell I'm not making this assumption anywhere. Transaction state is managed per-connection, and the representation of a connection in Django is very straightforward. > And last (and probably least) -- coordinated distributed transactions and two- > phase-commit are not really supported by Django, and if you want them you > need > to write backend-specific code (probably a custom backend -- I haven't had > the > [mis]fortune to need to do this yet). I suspect such code would be affected, > I'm not sure if it becomes easier or harder to write. I know the issue is > mostly theoretical, and even if there is a problem with it, that's not a > blocker; still, I thought it was worth a mention. I've never thought about this and I'm not sure what the interactions are. At worst, you can restore the previous behavior by setting the connection's max age to zero. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
