Package dev.relism.flash.ext.data.core
Class ResourceRegistry
java.lang.Object
dev.relism.flash.ext.data.core.ResourceRegistry
-
Method Summary
Modifier and TypeMethodDescriptionstatic voidstatic voidbind(TxResourceKey key, Object value) static voidcleanup()static voidclear()static voidfireBeforeCommit(boolean readOnly, int fromIndex) RunsTxSynchronization.beforeCommit(boolean)on the synchronizations registered fromfromIndexonward, while their transaction is still active and its resource still bound.static voidfireSynchronizations(TxOutcome outcome, int fromIndex) Fires (and removes) the synchronizations registered fromfromIndexonward — the ones belonging to the transaction now completing.static <R> Rget(TxResourceKey key, Class<R> type) static <R> RgetOrNull(TxResourceKey key, Class<R> type) static booleanisBound(TxResourceKey key) static intHow many synchronizations are registered right now — captured by a transaction manager when it opens a new transaction, and handed back tofireSynchronizations(dev.relism.flash.ext.data.core.TxOutcome, int)on completion so that transaction only fires its own.static voidunbind(TxResourceKey key)
-
Method Details
-
bind
-
isBound
-
unbind
-
clear
public static void clear() -
cleanup
public static void cleanup() -
get
-
getOrNull
-
addSynchronization
-
synchronizationCount
public static int synchronizationCount()How many synchronizations are registered right now — captured by a transaction manager when it opens a new transaction, and handed back tofireSynchronizations(dev.relism.flash.ext.data.core.TxOutcome, int)on completion so that transaction only fires its own. See there for why that matters. -
fireBeforeCommit
public static void fireBeforeCommit(boolean readOnly, int fromIndex) RunsTxSynchronization.beforeCommit(boolean)on the synchronizations registered fromfromIndexonward, while their transaction is still active and its resource still bound. UnlikefireSynchronizations(dev.relism.flash.ext.data.core.TxOutcome, int)this leaves them registered: they still have their post-completion callbacks to come. Exceptions propagate on purpose — a beforeCommit that throws vetoes the commit, seeTxSynchronization.Snapshots before iterating, so a callback that registers further synchronizations (a nested
Data#afterCommit) doesn't mutate the list mid-loop. Those new ones join the transaction's post-completion callbacks without getting abeforeCommitof their own, which is the only coherent answer once the pass is already running. -
fireSynchronizations
Fires (and removes) the synchronizations registered fromfromIndexonward — the ones belonging to the transaction now completing. Everything before that index was registered by an enclosing transaction that is merely suspended, not finished: a REQUIRES_NEW inner transaction sets its own baseline, so committing it no longer drags the outer's pending callbacks along — which fired them early, and with the inner transaction's outcome, for an outer transaction that might still roll back.
-