Link between RetryingTransactionHelper and the table alf_transaction

[eroux]

Hi,

I've a scheduled action which process a lot of nodes. In order to not rollback all process when there is an error on a node, i've planed to execute the process of each node in a new transaction (with the RetryingTransactionHelper) = One transaction per node.

My question is : Is there a link between the component "RetryingTransactionHelper" and the table "alf_transaction" in the database ?

I don't want to increase the number of record in the "alf_transaction" table with transactions with only one node. "alf_transaction" table is used during the indexation process.

Or is there a risk to have a lot of records in the "alf_transaction" table with one node in each transaction ?

Thanks in advance.

Regards,
Emmanuel

[afaust]

There is no direct link between RetryingTransactionHelper and alf_transaction. Just by using the RetryingTransactionHelper you are not creating new entries in that table. However, if you are modifying the state of a node, the NodeService / NodeDAO will create an entry in alf_transaction for the transactional context and use that to group all the changed nodes of that transaction, which is then used e.g. for index tracking in SOLR. So if you plan to process a lot of nodes it is usually recommended to do some batch / bulk processing instead of "one node in each transaction". It is typically safe to do batches of 50 - 250 nodes per transaction, and even up to 1000 nodes may not be problematic if the changes are trivial and not affecting nodes with content...

[eroux]

Thank you Axel.

In fact i have to create about 50 documents in each launch of my scheduled action. I don't want to rollback the creation of 49 documents if there is an error on the last. So, i've thought to use a new transaction for each node creation.

Do you have an other idea ? (maybe manage by myself the catch block in my transaction ?)

Regards,

Emmanuel

[afaust]

I don't know what errors you expect, but the recommended approach would usually be to check for any potential error conditions BEFORE creating the document, and potentially skip those that could fail. There are very few exceptions that are safe to handle yourself via a simpled catch block, as they may already have marked the transaction as failed / for rollback before you get a chance to handle them.