.NET Client Pro Tip!

Create one connection per app!

I was going through some code when I realized that I was creating a new EventStore connection for each operation.

Switched it out for a globally available connection, and the app magically got faster. I’m talking orders of magnitude faster.

Whoops :wink:

Yup - the XML documentation for EventStoreConnection tells you that too :wink:

It may be worthwhile to put a flyweight on top of an internal pool of
connections to allow for a more idiomatic using(new
EventStoreConnection) { }

Yup, we might want to consider redesigning some of that stuff, making the API more consistent and putting out a 4.0 client release.

Not sure where this stands, but I’m running into the need for this. I’m testing some failure scenarios.

When I have a naive static readonly connection, if the connection ever dies, the object is disposed and can’t be used anymore. The API can’t recover and must be restarted.

So, I have to make it mutable, put locking around it, hide it in a class, etc. But I do not see a way to directly ask the connection object if it is disposed.

There appear to be two ways to know if the connection is good. #1 subscribing to one of the events exposed by the connection. (I think it’s the Closed event, but not sure because some are raised even though the connection will retry.) #2 Just trying an operation and catching an ObjectDisposedException.

Were it not for the expense, I would probably just create a connection on every request to make sure I have a live one.

So yeah, some sort of connection pooling / flyweight would be a great help here, especially for stateless connections, where the use case is just to make sure it’s up before processing an operation.

Agreed. Don’t make us rely on dropped subscription events alone.

I should also mention that setting the MaxReconnections to a high number is also an option. The connection will basically never close, but the API call will just basically hang until the ES comes back. I’d rather the default behavior where it retries a little and errors out. Then each new API call attempts to reconnect. Having an error is better than hanging in silence. Just need an easier way to recover from the disconnection.