Considered a com.datastax.driver.core.Session instances pool indexed by KeySpace for vertx instances

[cmuxiaodong]

In the DefaultCassandraSession, it creates the a com.datastax.driver.core.Session instance for a vertx.

From the the API documents: http://docs.datastax.com/en/drivers/java/3.0/ (same for 2.1 and 2.0), The driver's Session instance is a threadsafe and it even recommends "As a given session can only be "logged" into one keyspace at a time (where the "logged" keyspace is the one used by query if the query doesn't explicitely use a fully qualified table name), it can make sense to create one session per keyspace used."

Have you considered the Session pool(or map) for the vertx instances which can retrieved the Session by using the KeySpace? Since the current implements may not fully leverage the Session.

[cmuxiaodong]

Sharing another doc for the Session:
https://docs.datastax.com/en/latest-java-driver/java-driver/fourSimpleRules.html

[jtruelove]

@adrianluisgonzalez what are your thoughts on this? I had been taking a different approach of one session per verticle instance. Based on that link and the javadocs http://docs.datastax.com/en/drivers/java/3.0/com/datastax/driver/core/Session.html seems like that is probably wrong. I don't know if this has always been the case but 3.0 definitely seems like the advice is one session per keyspace per jvm. Next question then in my mind is, are there any implications on which event loop you marshall cassandra responses back onto? In example you have multiple verticle instances hitting cassandra and every response is marshalled back on the same instance event loop.

[jtruelove]

Looking at the vertx-cassandra code I think it's fine given the FutureUtils does a getOrCreateContext call, I'll submit an update to the docs to advice people to only use one Session. You could maybe detect if people used the session in the wrong way and maybe through a warning.