How the Transaction-Replay Works in Cassandra implementation?

All the transactions are saved in 4 tables in Cassandra database.

es_transaction_retention table is responsible for keeping the transactions data until the transaction is completed successfully. It helps to track the missing transactions. even if it is a very rare case the transaction can be missed for some reason like computers are not shut down gracefully. we talked above already that we can not identify the transaction based on the status like in SQL databases due to the structure of the transaction data is saved. this table keep the transaction data until the transaction is completed. and if some transactions were missed for some reason those transactions can be identified.

There are two tables are called es_transaction_retention_odd and es_transaction_retention_even. the names are based on when the tables are scanned for identifying the missing transactions. if the transaction is initiated in odd date, the transaction saves in the es_transaction_retention_even table. and if the transactions is initiated in even date, the transaction saves in the es_transaction_retention_odd table. the reason is that after initiating the transaction it should be kept some period for ending the transaction. this is called as the retention time. in stacksaga cassandra implementation the retention time can be minimum 24 hours to maximum 48 hours based on the transaction initializing time.

the es_transaction_retry_bucket tables are created based on the given configuration for stacksaga.cloud.agent.retry-fixed-delay. the default fixed-delay value is 2 minutes. that mean the retry scheduler is triggered every 2 minutes so withing one hour the retry scheduler is triggered 30 times. then 30 tables are created when the application is started if the tables are not existed like,

For instance, if you customize the stacksaga.cloud.agent.retry-fixed-delay value as 10, the table count will be 6 (60/10).

Let’s see how the table is selected when the transaction is saved in one of es_transaction_retry_bucket tables.

When a transaction is initiated by the stacksaga-framework, the transaction is saved on es_transaction and es_transaction_tryout tables. after that the transaction should be saved in one of the es_transaction_retry_bucket tables. just imagine if the transaction is initiated at 2022-01-01 00:00:00.000 the transaction is saved on the farthest es_transaction_retry_bucket table from that time. according to this transaction the table will be es_transaction_retry_bucket_60.

if the transaction is processed successfully without any retryable error, the record will be deleted from the table at the end of the transaction. but if there is an

es_transaction_retry_bucket_* table is used for identifying the retryable transactions. This table is used in StackSaga in a quite different approach from the regular approach that a table used. This table is used as a data bucket. that means the data that stored in this table is deleted after using.

es_transaction_retry_bucket is a not a single table. it’s actually the prefix of the table name.

you know that already prefixed tables are used for identifying the retryable transactions. so when a transaction is initiated it is saved in the es_transaction_retry_bucket table apart from the es_transaction and es_transaction_tryout table.

If you have referred the SQL implementation you may have noticed that you can use one shared database for many services as the even-store, and also you can deploy agent service for each service separately. for instance, if you use a single (shared) database for order-service and payment-service as the event-store you can deploy separate agent-service for each service like order-service-agent and payment-service-agent. but in Cassandra implementation you can not deploy different agent services separately for each services of you have shared one database for those services. if we consider the example, if you are using single Cassandra database for the order-service and payment-service you cannot deploy separate agent services for each of them like order-service-agent and payment-service-agent. you must deploy only one agent for order-service and payment-service with a given name as you prefer.