Fail fast when reading/writing and keep retrying when handling subscriptions

EventStoreDB
1

Is it posible to use the same connection to fail fast when reading/writing and at the same time keep retrying forever when handling events from a subscription? The recommended pattern is to use just a single connection per app.

2

No because a catch up subscription might be reading as well. Using 2
connections is totally fine. The advice is more don't do using(var
conn = new EventStoreConnection(...))

3

If I should not do using(var con = new …), how can I fail fast without the need to create a whole new connection?

4

you still make a new connection ^^^ was talking about a connection per request.

5

What about

  1. A lot of Concurrent requests using the same connection

  2. The network is down, all requests fails at the same time

  3. All requests then attempts to create a new connection at the same time to replace the old one (that is what happens to me)

  4. All attemps succeeds… but is not that a waste of resources?

6

I have a single connection per role/context, with synchronised access. It’s not ‘handed out’ until it’s connected. Might be some contention there but with our load it’s not a problem at all…

/Peter

7

You don't seem to be understanding. You should *NOT* be using a
connection/request.

Use a connection. All operations on it are async. If operations fail
reconnect it. Operations can decide if they want to retry or not.

8

Im sorry for misunderstanding. What happens to me is that I have a connection that keeps reconnecting forever, so, when I try to read/write it NEVER fails. I dont want to disable the reconnection feature, I just want the operation to fail to let the user decide what to do, but, in the meantime let the reconnection stuff do its work to recover the lost connection, so when the user decide to try again, it will succeed

9

You can do this on your own.

10

btw there is also a retry count setting but this only applies for
actual retries (eg if network is down it won't count them)

11

Thanks Greg. I just did not wanted to write my own “framework” around Event Store. I can see why SqlConnection has a connection pool to handle this kind of problems

12

Connection handles most of the cases. The reason connection pool
exists has little to do with the opening/closing of connections, it is
because operations on the connection are synchronous (eg req/resp). ES
connections are async + bidirectional which removes the need of a
connection pool.

As for writing a "framework" its < 10 lines of code?! not sure how you
would consider this a framework. Set the retry count to 0 and on
connection closed try to make a new one. You get fail fast behaviour
(first failure results in exceptions to callers, you can control back
off etc, and your callers can determine their retry strategies)

13

Thanks Greg! That is the answer I wanted to get :slight_smile: