CODEWITHSUNDEEP
c#asp.net-web-apinosqlcassandra
bq51
bq51

Reputation: 51

Permanent connection to cassandra or connection per request?

I'm right now implementing my own UserStore for WebApi 2 so it works with cassandra. My question is, if i should close the connection after a request and reconnect to cassandra for the next request.

Right now i am establishing the connection at startup of the application and passing a cassandra Context to the UserStore to work with. the connection is closed when i shut down the application.

I'm wondering if e.g. 10 people register at the same, is this possible with only one connection?

static Startup()
        {
            PublicClientId = "self";

              //Connecting to Cassandra
            Cluster cluster = Cluster.Builder().AddContactPoint("127.0.0.1").Build();
            Session session = cluster.Connect();

            Context context = new Context(session);

   //passing context
            UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(context));

            OAuthOptions = new OAuthAuthorizationServerOptions
            {
                TokenEndpointPath = new PathString("/Token"),
                Provider = new ApplicationOAuthProvider(PublicClientId, UserManagerFactory),
                AuthorizeEndpointPath = new PathString("/api/Account/ExternalLogin"),
                AccessTokenExpireTimeSpan = TimeSpan.FromDays(14),
                AllowInsecureHttp = true
            };
        }



//UserStore Method for Registration
    public virtual Task CreateAsync(TUser user)
    {
        if (user == null)
        {
            throw new ArgumentNullException("user");
        }
        var usertable = _context.GetTable<TUser>("users");
        //insert user into table
    }

Upvotes: 1

Views: 2020

Answers (2)

Alex Popescu
Alex Popescu

Reputation: 4012

The DataStax C# driver already provides connection pooling internally, thus the recommended way to use the driver is to use a Cluster instance per your C* cluster and a Session per keyspace.Basically initialize these at the startup of your app (nb you can also prepare the PreparedStatements too), reuse these across request, and close them for cleanup when stopping the app (for upgrading, etc).

I'd strongly recommend you to give a quick read of the C# driver docs. It shouldn't take you long and you'll know more about what's included in the driver.

Upvotes: 0

Arya
Arya

Reputation: 2153

When you are deciding if you should have connection pooling or not, there is typically 2 questions you need to answer:

  1. What is the cost of establishing connection every time?

Establishing connection on some networks like EC2 is more expensive depending on the type of network and machines and your architecture setup. It can take several milliseconds and that adds up to your query time if you are establishing connections every time. If you care about saving those milliseconds, then pooling connections is a better option for you.

  1. Connections to databases are resources managed by your OS that your Application Server and DB server are holding onto while being consumed or sleeping. If your hardware resources are low, the connections should be treated like files. You open them, read from, or write to them, then close them. If you don't have hardware resource constraints then don't worry about pooling resource.

On the Cassandra side if you set your rpc_server_type to sync, then each connection will have its own thread which takes minimum of 180K and if you have a lot of clients, then memory will be your limiting factor. If you chose hsha as rpc_server_type, then this won't be a problem.

Read this: https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L362

About your application performance:

Ideally if you are using Cassandra with a multi-node setup, you want to distribute your requests to multiple nodes (coordinators) so that it scales better. Because of this it is better if you don't stick with the same connection as you will always be talking to the same co-ordinator.

Secondly, if you are multi-threading, you want to make sure your connection is sticking with the same thread while being used for the duration of each query to Cassandra, otherwise, you may end up with race conditions where one thread is updating resources of the connection which is already being used (e.g. trying to sent query packets to server, when it previously was waiting for a response from server).

I recommend implementing a thread-safe connection pool and open several connections on startup of your application and randomly use them for each of your requests, and kill them when your application server stops. Make sure you consider changing the rpc_server_type in Cassandra if you have hardware constraints.

Upvotes: 4

Related Questions