RE: lots of ReadConflictErrors

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

which is hard to follow compared to having the full execution flow visible while reading mainFn.
Even granted that if it were complex some breakdown into smaller functions would be useful, the natural version of such a breakdown would not necessarily separate the transactions from the other stuff.

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

Did you look at the link I posted in the previous message?

Jim

On Fri, Oct 7, 2016 at 5:04 PM, Boylan, Ross <[email protected]> wrote:
> No immediately appealing alternative strikes me.  Using the full code required to retry at each transaction is ugly.  The retry logic can be put in a function (or a function decorator as suggested in the thread you mention), but this means the actual code to execute within the transaction ends up in a separate function.  That would make it difficult to follow what the main body of code was actually doing.  If the operation to be transactionalized is trivial enough to fit in a lambda that might not be such an issue, but that doesn't seem general enough.
>
> If one could do
> transaction.begin_with_retries(4)
> ..... stuff
> transaction.commit()
> that would be very convenient, but that might require some weird operation on the python stack, if it's doable at all.
>
> Maybe a decorator could rewrite the real function to achieve the same effect?
>
> Ross
> ________________________________________
> From: [email protected] [[email protected]] on behalf of Jim Fulton [[email protected]]
> Sent: Friday, October 07, 2016 5:57 AM
> To: Boylan, Ross
> Cc: Jim Fulton; zodb ‎[[email protected]]‎
> Subject: Re: [ZODB] lots of ReadConflictErrors
>
> You've found a bug. :(
>
> I hate the attempts API.  Hate hate hate it. I wrote it in an attempt
> :) to try to make the flawed Python context model work.  It's very
> hard to reason about, because it's a stupid twister of a model. Using
> it is an incantation at best and we obviously can't get the
> implementation right. I'm sorry.
>
> I'm going to replace it
> (https://groups.google.com/forum/#!topic/python-transaction/3eUzBzX2sRU).
> Soon. (I plan to provide a PR in the next few days.)
>
> Jim
>
> On Thu, Oct 6, 2016 at 7:56 PM, Boylan, Ross <[email protected]> wrote:
>> Short version:  transaction retries seem to execute multiple times even if all executions succeed.
>>
>> While trying to come up with a simpler example I had this code at the end:
>> aTM = transaction.TransactionManager()
>> conn = db.open(aTM)
>> for attempt in aTM.attempts(10):
>>     with attempt:
>>         aTree = conn.root.foo
>>         print("Inserted {} objects from {} threads: {}".format(len(aTree), nThread, list(aTree.keys())))
>> I had the impression from http://www.zodb.org/en/latest/guide/transactions-and-threading.html
>> that this should have one successful execution (because the for attempt .. with attempt: is said to be equivalent to an earlier code block that had that semantics; also the example at http://zodb.readthedocs.io/en/latest/transactions.html#retrying-transactions is consistent with this interpretation).  But it seems to execute 10 times, i.e., the print statement is executed 10 times.  I'll add that at this point all the writer threads had completed, so I don't think an error should be possible.  I was trying to use the retry formulation everywhere to avoid mixing different transaction idioms.
>>
>> So, have I misunderstood?  Coded it wrong? Found a bug?
>>
>> Ross
>>
>> P.S. If I've understood earlier advice I can do without the explicit transaction manager; I'm just trying not to change too much at once.
>> ________________________________________
>> From: [email protected] [[email protected]] on behalf of Jim Fulton [[email protected]]
>> Sent: Thursday, October 06, 2016 3:13 PM
>> To: Boylan, Ross
>> Cc: Jim Fulton; zodb ‎[[email protected]]‎
>> Subject: Re: [ZODB] lots of ReadConflictErrors
>>
>> On Thu, Oct 6, 2016 at 5:40 PM, Boylan, Ross <[email protected]> wrote:
>>> "readCurrent" is not in my code or in the stack traces I sent in this email thread, and so I don't know why you say I'm calling it.
>>
>> The stack trace ends in checkCurrentSerialInTransaction.  This is a
>> storage method that's called during the commit process if something
>> has called readCurrent on the connection in the transaction being
>> committed.
>>
>> So a mystery for you to solve is what in your application is calling
>> readCurrent.
>>
>> Jim
>>
>> --
>> Jim Fulton
>> http://jimfulton.info
>
>
>
> --
> 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.



--
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.