I am seeing an unconfigured table error when I execute a batch statement(not consistent).
In the batch statement, I am having several prepare statements(10) Few of the prepare statements(2 of them) are created by another session object(Different from what is used to execute the batch statement), which points to tables in different key space
Error occurred while executing the batch "Unconfigured table myTable". Interestingly the keyspace of this table & the session's default keyspace are both same
Using single node Cassandra(Also looks no schema disagreement is there)
The issue is not consistent, I am suspecting that few of the prepare statements in batch are discarded in Cassandra when this issue arises
Not seeing any logs in Cassandra , so guess that driver is throwing the exception
Is it because I am using prepare statements being created from different session?
I am just trying to understand before fixing it, so if any official docs(Or Bug no) are there which points to this issue, pls share
I tried to debug the issue and find the root cause, if the cause is what I am assuming I can fix it
My guess is that you don't specify the keyspace name with the table name in your CQL statements so with multiple session objects instantiated in your app, the session which has a different keyspace configured won't be able to execute statements which have tables for another keyspace.
It is unnecessary to create two sessions in the one application to deal with multiple keyspaces. In fact, creating multiple sessions is not recommended.
The best practice is to create just one session object that is shared across the entire application. If you have multiple keyspaces, you should use fully-qualified names by specifying the keyspace name together with the table name. For example:
SELECT ... FROM ks_name.tbl_name WHERE ...
Sessions are heavyweight objects which use a lot of resources particularly since they create and maintain connections to every node in the cluster. This is unnecessary since a single session can handle thousands of queries on its own.
For details, see Best practices for using the Cassandra drivers. Cheers!