Package tech.ydb.yoj.repository.db

Interface TxManager

All Known Implementing Classes:
DelegatingTxManager, StdTxManager
public interface TxManager

  • Method Details

    • withName

      TxManager withName(String name)
      Set transaction name used for logging and metrics.

      Since name is used as metric label, there should be limited numbers of names used for transactions. Normally one per code occurrence.

      Parameters:
      name - used for logging and metrics, not null

    • withLogContext

      TxManager withLogContext(String logContext)
      Parameters:
      logContext - dynamic context used for logging.

    • separate

      TxManager separate()
      Mark transaction as explicitly separate from current transaction. Otherwise, you will be failed or WARNed about initiating a new transaction while already being in a transaction

    • delayedWrites

      TxManager delayedWrites()
      Enable pending write queue in transaction and execute write changes right before the transaction is committed.

    • immediateWrites

      TxManager immediateWrites()
      Disable pending write queue in transaction and execute write changes immediately.

    • noFirstLevelCache

      TxManager noFirstLevelCache()
      Turn off first level cache

    • failOnUnknownSeparateTx

      TxManager failOnUnknownSeparateTx()
      Fails if you try to create a separate transaction inside other transaction. TxManager with this setting is good to use in tests. Call separate() before start transaction if you really need to create a one transaction inside other transaction.

    • withName

      default TxManager withName(String name, String logContext)
      Short cut for: 
      withName(name).withLogContext(logContext)

    • withMaxRetries

      TxManager withMaxRetries(int maxRetries)
      Sets maximum number of retries for each tx() call:
      Parameters:
      maxRetries - maximum number of retries (>= 0)
      Throws:
      IllegalArgumentException - if retries < 0

    • withDryRun

      TxManager withDryRun(boolean dryRun)
      Marks the transaction as dry-run. If transaction is marked as dry-run, its changes will be rolled back but no exception will be thrown and transaction result will be returned.

    • withVerboseLogging

      default TxManager withVerboseLogging()
      Configures verbose logging for this transactions's execution. Short representations of DB queries performed and partial results of these queries will be logged.
      See Also:

    • withBriefLogging

      default TxManager withBriefLogging()
      Configures brief logging for this transactions's execution. Only total time spent in DB session and commit/ rollback timings will be logged.
      See Also:

    • noLogging

      default TxManager noLogging()
      Disables logging of this transaction's execution. You will still see transaction result messages in the logs, e.g., "runInTx(): Commit/Rollback/...".

    • withLogLevel

      TxManager withLogLevel(TransactionLog.Level level)
      Changes logging verbosity.
      Parameters:
      level - minimum accepted log message level, e.g., DEBUG for DB queries

    • withLogStatementOnSuccess

      TxManager withLogStatementOnSuccess(boolean logStatementOnSuccess)
      Flag for managing logging transaction statement on success.

    • withTimeout

      TxManager withTimeout(Duration timeout)
      Changes transaction timeout. If the timeout elapses before transaction finishes, DeadlineExceededException or QueryCancelledException might be thrown.
      Parameters:
      timeout - transaction timeout

    • tx

      <T> T tx(Supplier<T> supplier)
      Performs the specified action inside a transaction. The action must be idempotent, because it might be executed multiple times in case of transaction lock invalidation.
      Parameters:
      supplier - action to perform
      Returns:
      action result

    • tx

      void tx(Runnable runnable)
      Performs the specified action inside a transaction. The action must be idempotent, because it might be executed multiple times in case of transaction lock invalidation.
      Parameters:
      runnable - action to perform

    • readOnly

      TxManager.ReadonlyBuilder readOnly()
      Start a transaction-like session of read-only statements. Each statement will be executed separately, with the specified isolation level (online consistent read-only, by default).

      YDB doesn't currently support multi-statement read-only transactions. If you perform more than one read, be ready to handle potential inconsistencies between the reads.

      You can also use readOnly().run(() -> [table].readTable(...)); to efficiently read data from the table without interfering with OLTP transactions. In this case, data consistency is similar to snapshot isolation. If perform more than one readTable(), be ready to handle potential inconsistencies between the reads.

    • scan

      TxManager.ScanBuilder scan()
      Start a transaction-like session of scan queries. Each query will be executed separately. Scan query consistency is similar to snapshot isolation, and these queries efficiently read data from the snapshot without interfering with OLTP transactions. Be ready to handle potential inconsistencies between the reads if you perform more than one scan query.

    • getState

      TxManagerState getState()
      Returns:
      information about current transaction settings set for this instance of TxManager