Package dev.relism.flash.ext.data.core

Interface TxSynchronization

public interface TxSynchronization

Lifecycle hooks for one transaction, registered through Data#afterCommit (or ResourceRegistry.addSynchronization(dev.relism.flash.ext.data.core.TxSynchronization) directly) and fired by the TxManager that owns the transaction they were registered in.

Every callback belongs to exactly one transaction — the innermost one active at registration time — and fires exactly once, when that transaction completes. A joined (REQUIRED) inner transaction is not a transaction of its own, so callbacks registered inside one wait for the outermost commit; a REQUIRES_NEW transaction is, so completing it fires only its own callbacks and leaves the suspended outer transaction's alone.

Where each hook sits relative to the commit

• beforeCommit(boolean) — immediately before the real commit, with the transaction still active and its session/connection still bound. This is the only hook that can still write through that same resource and have the write land in the same atomic unit: flush a buffer, stamp an audit row, materialize a derived value. Skipped entirely when the transaction is already rollback-only, since there is no commit to precede.
• afterCommit() / afterRollback(), then afterCompletion(TxOutcome) — after the transaction has completed and its resource has been unbound. Nothing done here is part of the transaction: a callback that opens its own transaction gets a fresh one instead of joining the one that just finished, which is what makes this the right place to refresh a cache, enqueue a message, or notify anything outside the database.

Failure

Throwing from beforeCommit(boolean) vetoes the commit: the transaction is rolled back, afterRollback()/afterCompletion(TxOutcome) fire with TxOutcome.ROLLED_BACK, and the exception propagates to the caller. That is the point of this hook running before the commit rather than after — it can still refuse.

The post-completion hooks have no such power: the transaction is over by the time they run, so an exception from one propagates to the caller but changes nothing already committed, and stops the callbacks queued behind it.

Method Summary

Modifier and Type	Method	Description
default void	afterCommit()	Runs after a successful commit, with the transaction's resource already unbound.
default void	afterCompletion(TxOutcome outcome)	Runs after afterCommit()/afterRollback(), whichever applied.
default void	afterRollback()	Runs after a rollback, with the transaction's resource already unbound.
default void	beforeCommit(boolean readOnly)	Runs inside the transaction, immediately before it commits — see the interface javadoc.

Method Details

beforeCommit

default void beforeCommit(boolean readOnly)

Runs inside the transaction, immediately before it commits — see the interface javadoc. Throwing from here rolls the transaction back instead of committing it.

Parameters:

readOnly - whether the transaction was opened read-only, so a callback that would otherwise write can skip work it is not allowed to do

afterCommit

default void afterCommit()

Runs after a successful commit, with the transaction's resource already unbound.

afterRollback

default void afterRollback()

Runs after a rollback, with the transaction's resource already unbound.

afterCompletion

default void afterCompletion(TxOutcome outcome)

Runs after afterCommit()/afterRollback(), whichever applied.