[jira] [Updated] (IGNITE-17579) TxStateStorage management

["Alexander Lapin (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-17579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Lapin updated IGNITE-17579:
-------------------------------------
    Description: 
h3. Motivation

Currently TxStateStorage is instantiated every time on PartitionListener instantiation, probably with incorrect storage path, that actually means that separate rocks instances will be also instantiated, that leads us to the unfortunate conclusion of inefficient cursors usage and whole set of excessive resource utilization.

 
{code:java}
new PartitionListener(
        partitionStorage,
        // TODO: https://issues.apache.org/jira/browse/IGNITE-17579 TxStateStorage management.
        new TxStateRocksDbStorage(Paths.get("tx_state_storage" + tblId + partId)),
        txManager,
        new ConcurrentHashMap<>()
){code}
{{{}{}}}All in all, instead of new TxStateRocksDbStorage() proper storage factory should be used like it's done for MVPartitionStorage.
h3. Definition of Done
 * Proper usage of storage factory for TxStateStorage is expected, meaning that same amount of resources is used for TxnStateStorage as for MVPartitionStorage.

h3. Implementation Notes
 * It's required to add new 
{code:java}
TxnStateTableStorage txnStateStorage();{code}
 method to InternalTable.
 * Add new interface TxnStateTableStorage with following methods
{code:java}
public interface TxnStateTableStorage {
    TxnStateStorage getOrCreateTxnStateStorage(int partitionId) throws StorageException;

    @Nullable
    TxnStateStorage getTxnStateStorage(int partitionId);

    CompletableFuture<Void> destroyTxnStateStorage(int partitionId) throws StorageException;

    TableConfiguration configuration(); 

    void start() throws StorageException;

    void stop() throws StorageException;

    void destroy() throws StorageException;
}{code}
Not sure whether we need TableConfiguration configuration();  methods, let's check it during implementation.
 * Add RocksDb implementation of aforementioned interface similar to RocksDbTableStorage
 * Implement new RocksDbTxnStateStorageEngine similar to RocksDbStorageEngine that'll be used in order to create TxnStateTableStorage
 * Update direct TxnStateStorage instantiations with proper storage instantiation pipeline.
 * It's not clear what DataStorageConfiguration to use, let's check this during implementation.

 

  was:{color:#3c4043}In order to persist txnState RocksDb based TxnStateStorage was introduced. However it's required to properly manage it: effectively create and start like it's done for data storage, etc.{color}


> TxStateStorage management
> -------------------------
>
>                 Key: IGNITE-17579
>                 URL: https://issues.apache.org/jira/browse/IGNITE-17579
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexander Lapin
>            Priority: Major
>              Labels: ignite-3, transaction3_rw
>
> h3. Motivation
> Currently TxStateStorage is instantiated every time on PartitionListener instantiation, probably with incorrect storage path, that actually means that separate rocks instances will be also instantiated, that leads us to the unfortunate conclusion of inefficient cursors usage and whole set of excessive resource utilization.
>  
> {code:java}
> new PartitionListener(
>         partitionStorage,
>         // TODO: https://issues.apache.org/jira/browse/IGNITE-17579 TxStateStorage management.
>         new TxStateRocksDbStorage(Paths.get("tx_state_storage" + tblId + partId)),
>         txManager,
>         new ConcurrentHashMap<>()
> ){code}
> {{{}{}}}All in all, instead of new TxStateRocksDbStorage() proper storage factory should be used like it's done for MVPartitionStorage.
> h3. Definition of Done
>  * Proper usage of storage factory for TxStateStorage is expected, meaning that same amount of resources is used for TxnStateStorage as for MVPartitionStorage.
> h3. Implementation Notes
>  * It's required to add new 
> {code:java}
> TxnStateTableStorage txnStateStorage();{code}
>  method to InternalTable.
>  * Add new interface TxnStateTableStorage with following methods
> {code:java}
> public interface TxnStateTableStorage {
>     TxnStateStorage getOrCreateTxnStateStorage(int partitionId) throws StorageException;
>     @Nullable
>     TxnStateStorage getTxnStateStorage(int partitionId);
>     CompletableFuture<Void> destroyTxnStateStorage(int partitionId) throws StorageException;
>     TableConfiguration configuration(); 
>     void start() throws StorageException;
>     void stop() throws StorageException;
>     void destroy() throws StorageException;
> }{code}
> Not sure whether we need TableConfiguration configuration();  methods, let's check it during implementation.
>  * Add RocksDb implementation of aforementioned interface similar to RocksDbTableStorage
>  * Implement new RocksDbTxnStateStorageEngine similar to RocksDbStorageEngine that'll be used in order to create TxnStateTableStorage
>  * Update direct TxnStateStorage instantiations with proper storage instantiation pipeline.
>  * It's not clear what DataStorageConfiguration to use, let's check this during implementation.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)