Question: Ignite client instance

[satishviswanathan]

I'm using Ignite dotnet library to create new instance of ignite client. I'm integrating in my microservice and through some end points it would be updating the cache. My question is , is it recommended to create a client for each client per api request ?

[ptupitsyn]

Ignite client is thread-safe and can handle many requests in parallel (multiplexing).

It is recommended to create only one long-lived instance (or a small pool of instances) and reuse them across all API requests.

[satishviswanathan]

@ptupitsyn - Thank you for your response.

Just to give a background of our use case. we have many microservices (with multiple instances) connect to Ignite. So basically we would be having one client / instance of a microservice. Also is there recommendation on establishing a client connection like using connection pooling in the DB world (I understand in the case of DB connection it is different as we don't reuse the connection). Just making sure I'm following the right standards for a highly transaction system.

[ptupitsyn]

I don't have any specific recommendations, it should work well with 1 client instance per microservice. Pooling is not necessary here.

[satishviswanathan]

Thank you. Appreciate your response.

[satishviswanathan]

@ptupitsyn - I have a sudo code of how my domain transaction is wrapped in a unit of work. Within the same transaction I'm trying to update by cache as well. Is this a good design approach to update by transaction DB and ignite in a single transaction. As soon as I add ignite in a transaction dotnet runtime upgrades the transaction as s 2PC resulting in npsql failure. I assume since I have a transaction opened and using ignite client put() is invoked then it joins to the existing ambient transaction as a volatile resource which is causing this.

Do you think this is possible ? From an application perspective I would like to have the state of the data in transactional DB and cache up-to-date at any point of time.

try
{
   using( var transactionScope = new TransactionScope(TransactionScopeOption.Required,
            new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted },
            TransactionScopeAsyncFlowOption.Enabled))
    {

           //NHibernate ORM using npgsql - create / update
          //Apache ignite - put() 

           transactionScope .Complete();
    }
}
catch
{
  // handle exception
}

[ptupitsyn]

Coordinating a transaction across two databases requires a two-phase commit: https://learn.microsoft.com/en-us/dotnet/framework/data/transactions/committing-a-transaction-in-single-phase-and-multi-phase

Thin client can only do a single-phase commit, so there is no guarantee of atomicity across two DBs.

• This is implemented in "thick" mode and works as expected with TransactionScope. Consider using a thick client.
• Alternatively, write your own logic to roll back the changes in DB 1 if commit fails in DB 2. Many consider this approach to be more efficient in micro-service scenarios.

[satishviswanathan]

@ptupitsyn Thank you for sharing your thoughts. If we do a saga pattern with rollback strategy then we can still stay with thin client right ?

[ptupitsyn]

If we do a saga pattern with rollback strategy then we can still stay with thin client right ?

Correct.