#24810: Reopen database connection automatically when no transaction is active
-------------------------------------+-------------------------------------
     Reporter:  aaugustin            |                    Owner:  nobody
         Type:  New feature          |                   Status:  new
    Component:  Database layer       |                  Version:  master
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by binary):

 Replying to [comment:6 aaugustin]:
 > Yes, these are the reasons why this ticket exists. Patches *that do not
 ignore transactional integrity* welcome.
 So I gave it a humble try.

 There is no problem in case the trouble happened inside a transaction
 because in case error happened and was caught by the Atomic, the
 connection will be closed in one of the places like
 [https://github.com/django/django/blob/master/django/db/transaction.py#L230
 this]. And next transaction will work without any problem as connection
 will be re-established because django is now aware that the current one is
 not an option any more.

 It's still a problem in autocommit mode though because in this case
 connection won't be closed and will remain in a broken state, so in case
 we try to obtain a cursor again, we'll get the InterfaceError exception.
 So the code like:

 {{{
 def do_query():
     return Model.objects.first()

 def loop():
     while True:
         try:
             print do_query()
         except:
             print 'shit happened'
         sleep(5)
 }}}

 will stop working after first disconnect.

 At first I tried to intercept InterfaceError at the moment we are
 obtaining a cursor and OperationalErorr at the execute method, but then I
 realized that such a problem may happen in other methods, like fetchone or
 anywhere else, so eventually I came to just intercept it in the
 DatabaseErrorWrapper and close the connection if one of those errors
 occured but only in case we are not inside a transaction, as this case is
 covered already and it may break that code. Here's the commit:
 
https://github.com/jbinary/django/commit/568a4eb573c7fce2fdec2d1578b2db4f3d0e51fd

 After that, that code above starts to work even after disconnect.

 I have no any idea if this is the right approach, and I have no idea how
 to write tests for this yet. But if anyone will tell this one is a worthy
 approach, I'll try to think about tests too. (but advices are welcome,
 ofc)

--
Ticket URL: <https://code.djangoproject.com/ticket/24810#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2f71b8e271d2b77c0f501e22d21a073d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to