Connection best practices

EventStoreDB
#1

I have a few questions:

  1. What would be the preferred way to handle event store connection?

a. To open 1 connection per transaction;

b. To open 1 connection per application.

  1. What would be the preferred way to handle subscriptions?

a. Subscribe from another connection to all streams, on separate endpoint, to populate denormalized views? What happens when endpoint is down?

b. Subscribe when appending events?

Thanks in advance.

#2

Hi,

yeah I too would like to know the best way to handle an event store connection, for example in a web application.

Would each request open up it’s own connection to save an event, or would there be one connection per application?

I’ve found this blog post

http://geteventstore.com/blog/?p=7

“It is important to note that all operations on a connection are asynchronous. This results in a different usage pattern than those who are familiar with say a SqlConnection. Because all operations are asynchronous a single connection can be used by many threads concurrently. This is also exposed through the connection interface by the returning of Tasks as opposed to synchronous behaviours.”

Is there an example/best practice of how to manage a single connection within a web application?

And would there be a difference if you cared if the event was saved or not?

E.g. fire and forget, rather than waiting for the task to complete before ending the web request?

Kind Regards

Ian

#3

A connection can be shared between many callers as the protocol is purely asynchronous. If you wanted to use connection per request you would want to do a flyweight on top of the connection. Is the flyweight an easier model? Would it help if we put it in the client API? Very few applications would need more than two connections

#4

Thanks for the quick reply

Could do with seeing an example of sharing a connection in a web application,
and would you have to wait for the task to complete, or could you do fire and forget?

E.g. say I wanted to log an event that a user had visited a particular page, would that page send an event to the shared connection and then have to wait for that event to be processed?

Do I need to worry about how long that wait is going to be for that message to be processed, or will it be so quick (even under heavy load) that I don’t need to worry about it?

Kind Regards

Ian

#5

If you look the API has two offerings.

The first would be Append() the other is AppendAsync that returns you
a task. The first calls the second and blocks on the task. Generally I
would call the async method in most cases. These tasks can be used
with the await keyword in C#.

Depending on usecase sometimes I will want to block on it being
written sometimes I won't. As an example if in a http handler I wanted
to log someone came to page X. I normally don't care if things
actually worked before continuing. If someone shut down the webserver
before, losing the data is no big deal. I also don't want to hold my
user until the write is complete. Other times I do want to hold my
user (say processing a business command the user executed). It really
depends on my use case.

As for how to share a connection. I assume you are using a MVC
framework? You would just pass it as a dependency to your controller.
Assuming you are using a container you would just set its life cycle.

Cheers,

Greg