topic Re: RetryingTransactionHelper learnings in Alfresco Archive

RetryingTransactionHelper learnings

jharrop — Wed, 04 Jun 2008 03:09:04 GMT

The key method in the above is: public <R> R doInTransaction(RetryingTransactionCallback<R> cb, boolean readOnly, boolean requiresNew)‍where: * @param requiresNew <tt>true</tt> to force a new transaction or * <tt>false</tt&

Re: RetryingTransactionHelper learnings

iru — Thu, 25 May 2017 08:20:26 GMT

Hi,

Sorry for pumping this up, but have not found many more references related to this topic.

Is RTH supposed to work with 'requiresNew' set to false?

Been debugging code (repo 5.2.f), and when an exception is thrown inside the for loop, it just quits it and does not retry,.. so, don't understand the utility of having this as a parameter, if it will never do as its name says (retry)

Guess i'm taking something for granted, .. any idea?

Re: RetryingTransactionHelper learnings

afaust — Fri, 26 May 2017 09:54:36 GMT

With requiresNew set to false, the retrying transaction helper will look at the current transaction before creating a new transaction. If a transaction is already active no new (nested) transaction will be created. If the existing transaction is incompatible with the requested value of readOnly, an error will be thrown. E.g. if you request a read-write transaction and the current one is a read-only, it will fail. The other way around - a read-only within a read-write - will work though.

If no new transaction is created, the handler cannot apply retrying behaviour. It is assumed that the already active transaction will deal with any retrying semantics in that case.

Re: RetryingTransactionHelper learnings

iru — Fri, 26 May 2017 10:46:13 GMT

Hi Axel!

Got that clear from reading the source code of RTH, but if a class is called "Retry Transaction" I would assume that, no matter the parameters, it does what it says, say.. "retry the transaction".

However, the value of the parameter requiresNew, makes the transaction not to retry.

Maybe it's a matter of naming, but I would have expected it to be called "Transaction" and then have a parameter called "retry" (boolean), that if set to true, retries by creating a new transaction.

Does that make sense?

Re: RetryingTransactionHelper learnings

afaust — Fri, 26 May 2017 13:39:19 GMT

To some extent it makes sense. As you may know "naming things" is one of the hardest problems in IT. The problem with your example of a "Transaction" class with "retry" parameter set to true is that I may not want the helper to create a new transaction if I am already in one with retrying semantics, so I would somehow have to check the context I am in to determine if I can or cannot use it.

Re: RetryingTransactionHelper learnings

iru — Mon, 29 May 2017 08:06:19 GMT

As you said "If no new transaction is created, the handler cannot apply retrying behavior".

Checking source code (5.2.f), this also applies, because when the #execute of the implementation fails with a Throwable, it's just rethrown, without retrying.

community-edition-old/RetryingTransactionHelper.java at master · Alfresco/community-edition-old · GitHub
So, they're both dependent tasks: retry requires new transaction.