-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: Ignite client instance #11336
Comments
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. |
@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. |
I don't have any specific recommendations, it should work well with 1 client instance per microservice. Pooling is not necessary here. |
Thank you. Appreciate your response. |
@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.
|
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.
|
@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 ? |
Correct. |
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 ?
The text was updated successfully, but these errors were encountered: