[ 
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:
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.

 


> 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)

Reply via email to