RE: retries (was lots of ReadConflictErrors)

I got curious about the method of rewriting the code.  My thought was that
with aTransactionManager.retry(n):
    some code
could be rewritten to the desired form.  It seems doable, if not necessarily advisable :)

Transforming the AST was mostly what I thought about, though there is another issue of how to arrange for the code to be fed through the transformer.


There are existing "macro" packages for  python that could help with both the rewrite and the hooks to activate it, though neither one that I looked at is Python3 ready--probably not too big a deal to fix.  Both seem to have hooks into python's usual method of  processing input.  The simpler https://pypi.python.org/pypi/karnickel only rewrites when you do "from x import foo", while the more complicated https://github.com/lihaoyi/macropy seems to have more extensive hooks.  Even the simple rewrites in karnickel probably are sufficient.

The rewritten code needs a variable to  count tries; I haven't found a good way to assure that the name won't collide with a variable in the real program.

Unfortunately, rewriting functions (which could potentially be done by a decorator) stumbles on the fact that function objects don't seem to record either their source code or any intermediate representation.  pypi gives several hits on decompiler, though trusting any of them--which means trusting them to keep up with the language as it evolves--seems problematic.  I looked at https://pypi.python.org/pypi/meta; it also is not fully with the python 3 plan.

A final point, if one sticks with using the "with"; the AST representation of with changed in python 3.3, when it became possible to have multiple arguments.  Handling with that included a retry specification and other things is certainly possible formally, but it's probably easier and safer not to allow such constructs.

In this respect it is unfortunate that python != lisp.
Ross
________________________________________
From: [email protected] [[email protected]] on behalf of Boylan, Ross [[email protected]]
Sent: Friday, October 07, 2016 4:14 PM
To: Jim Fulton
Cc: zodb ‎[[email protected]]‎
Subject: RE: [ZODB] lots of ReadConflictErrors

Ah, that goes a good way to meeting my concern.  But isn't that a pretty unusual, i.e., likely to be surprising and confusing, way to use a decorator, and, for that matter, the function definition that follows?  Function definitions don't usually execute the code of the function.

Realizing now that functions can be defined inline, i.e., nested, one could have the more verbose but, I think, more conventional,
  def mainFn():

      @transaction.manager
      def step1():
            # some code for your first transaction
     step1()

      @transaction.manager
      def step2():
          # and for the second
     step2()

Ross
________________________________________
From: [email protected] [[email protected]] on behalf of Jim Fulton [[email protected]]
Sent: Friday, October 07, 2016 4:01 PM
To: Boylan, Ross
Cc: Jim Fulton; zodb ‎[[email protected]]‎
Subject: Re: [ZODB] lots of ReadConflictErrors

On Fri, Oct 7, 2016 at 5:56 PM, Boylan, Ross <[email protected]> wrote:
> Yes; that's what I meant by the "thread you mention".  It seems to me it would lead to this kind of pattern (using your proposed decorator name):
>
> @transaction.manager.run
> def step1():
>     # some code for your first transaction
>
> @transaction.manager.run
> def step2():
>     # and for the second
>
> #etc
>
> def mainFn():
>     # so some stuff
>     step1()
>     # more computations here
>     step2()
>     # etc
>

Nope:

  def mainFn():

      @transaction.manager.run
      def step1():
            # some code for your first transaction

      @transaction.manager.run
      def step2():
          # and for the second

Or even:


  def mainFn():

      @transaction.manager.run
      def _():
            # some code for your first transaction

      @transaction.manager.run
      def _():
          # and for the second

The decorator *run*s the decorated function.

Jim

--
Jim Fulton
http://jimfulton.info

--
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.