Apologies, but I need to tag @michael.hunger directly on this question.
I need to know what atomicity guarantees exist (if any) for triggers created using apoc.trigger.add or apoc.trigger.install?
If the phase argument of a trigger is specified as before, is this absolutely guaranteed to be executed before the transaction is commited? i.e. to be effectively "atomic" within the transaction?
If the phase argument of a trigger is specified as after, is this guaranteed to be executed before anything else after the transaction is commited? (I am guessing no, and I can live with this, I just want to know for sure)
EDIT: I do see the documentation, and the difference between the description for after vs. afterAsync implies that in fact tiggers executed after will still be part of the transaction and block any other transaction, but I need a definitive answer.
Secondary question: is there any way of manually forcing a trigger refresh?
Thanks very much!
Hi Ben,
sorry for the delay, busy days.
The guarantees around triggers are not really tight, more a "best effort", eventually triggers need to be in the product.
The phases refer to the transaction event handlers in neo4j, where there is a beforeCommit and afterCommit callback function. The afterCommit is still in the transaction commit flow at the closing of the tx, but sometimes something is wonky there. But yes it is most likely blocking a tx from completing.
And you can't see deleted things anymore (imho)
That's why we introduced the afterAsync for things that users want to execute after tx flow is definitely through, but then some things are not accessible anymore, like deleted data.
1 Like
Thanks Michael, that's the clarity I was looking for! Okay, for things that absolutely must happen in the transaction I will only use triggers with the before phase.
I will create a PR for the APOC documentation where I include the core part of your answer regarding the guarantees and the connection between the phases to the transaction event handlers.
