GitLab

With this work, every transaction gets its own deadline, and (only) shorter deadlines can be applied on desired subparts of a transaction.

This prevents performance degradation from keeping a single transaction alive for an unexpected amount of time, which is especially detrimental to InnoDB transaction isolation.

Another application of this API is to provide a time-based limit to a long rendering process where a document-count-based limit would be too hard to quantify. Like for example listing many documents and preparing each for display, which can be achieved using something like (pseudo-code):

result = []
with Deadline(-2): # Reserve 2 seconds at the end of the current deadline to finalise response
  for row in portal_catalog(...): # Should be fast to take advantage of this pattern
    try:
      result.append(produceFullResult(row)) # May be arbitrarily slow
    except TimeoutReachedError:
      result.append(click_here_to_get_more_documents) # Tell user there may be more results
      break
return result # Contains all documents which could be processed until the inner deadline was reached

Checking the current deadline is to be explicitly done, in a few select places:

• database connectors (this merge request implements this for ZODB & ZMySQLDA)
• process spawning (document conversion, ...)
• other network adaptors (sftp, ...)

This approache is not supposed to protect against all cases. Especially, it is not supposed to protect against "while True: pass". This should be fine because:

• such issues are normally caught while developping, and not on a live production (I do not remember ever discovering such bogus code in production myself, not even caused by complex code or complex code interactions)
• python's lack of thread preemption at interpreter level would make such implementation complex, intrusive and likely slow

So covering such in-practice-non-existent edge-cases should not be worth the massive effort.

The publisher-based deadline is already in use as a proof-of-concept, and it very successfully reduced the number of runaway transactions on a real-life application.

The CMFActivity-based deadline is not in actualy use yet, as how to choose a duration without causing massive regressions is not clearly identified yet, while user-facing transactions are typically already limited by http proxy's timeout of a few minutes.

To make use of deadlines, ERP5 Software Release must be modified and updated so the proper configuration is generated (there is no merge request for this yet).

Some extra work may be needed to define deadlines in the WSGI publisher.

/cc @georgios.dagkakis @jerome @jm @jp @kazuhiko @romain @seb @tb @yusei