Class ResourceRegistry

java.lang.Object
dev.relism.flash.ext.data.core.ResourceRegistry

public final class ResourceRegistry extends Object
  • Method Details

    • bind

      public static void bind(TxResourceKey key, Object value)
    • isBound

      public static boolean isBound(TxResourceKey key)
    • unbind

      public static void unbind(TxResourceKey key)
    • clear

      public static void clear()
    • cleanup

      public static void cleanup()
    • get

      public static <R> R get(TxResourceKey key, Class<R> type)
    • getOrNull

      public static <R> R getOrNull(TxResourceKey key, Class<R> type)
    • addSynchronization

      public static void addSynchronization(TxSynchronization sync)
    • 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 to fireSynchronizations(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)
      Runs TxSynchronization.beforeCommit(boolean) on the synchronizations registered from fromIndex onward, while their transaction is still active and its resource still bound. Unlike fireSynchronizations(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, see TxSynchronization.

      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 a beforeCommit of their own, which is the only coherent answer once the pass is already running.

    • fireSynchronizations

      public static void fireSynchronizations(TxOutcome outcome, int fromIndex)
      Fires (and removes) the synchronizations registered from fromIndex onward — 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.