Open ansirotenko opened 2 months ago
Currently YOJ does not use YdbTransaction
internally, at all. YdbTransaction
has been introduced quite recently and is an experimental API (subject to sudden change) in the YDB SDK:
public interface Session implements AutoCloseable {
// <...>
@ExperimentalApi("New table transaction interfaces are experimental and may change without notice")
TableTransaction createNewTransaction(TxMode var1);
@ExperimentalApi("New table transaction interfaces are experimental and may change without notice")
CompletableFuture<Result<TableTransaction>> beginTransaction(TxMode var1, BeginTxSettings var2);
// <...>
}
We can try to implement YdbTransaction
interface in YdbRepositoryTransaction
(e.g. YdbRepositoryTransaction.getYdbTransactionWrapper()
, but this comes with limitations:
getStatusFuture()
will throw UnsupportedOperationException
. Also, implementing TableTransaction
is out of the question: we don't want to give users abilities to circumvent YOJ in performing queries in YDB transactiongetSessionId()
semantics if YDB session is not yet acquired or has been invalidated: it's complicated. Some possibilities:
null
IllegalStateException
getId()
will return null
transaction ID if YDB transaction is not yet established. This seems to be the way it is implemented in YDB SDK, so this should be fine.If you implement any solution that would allow to reuse yoj transactions to work with ydb topics, that would be good enough
Transaction support for ydb partitions is expected to be available in the fall. In our project, we use yoj to work with our tables everywhere. It is required to marry yoj transactions and ydb-java-sdk transactions to be able to write topic messages (also commit offset at read) at the same transaction for the table. Currently it is possible to access current transaction of the txManager, but it is not possible to create ydb-java-sdk transaction from it. 2 main issues are statusFuture and sessionId could not be extracted from the yoj transaction. Also it would be great to have txId generated upfront, not lazily (if this is ok, im not sure).
Overall if yoj transaction would provide method like getYdbTransaction that would return instance of tech.ydb.common.transaction.YdbTransaction, it would be the most preferrable way