If your client needs to support working with different keyspaces at that same time, then you need to have a mechanism to call set_keyspace() per operation. In your connection pool you can have something like getClient() which selects a node from the pool from your operation during a client session. In there you can call set_keyspace() and upon success, save the keyspace name in some local flag and next time you want to get the same client if the local flag has the same keyspace then you won't call set_keyssapce(). This is only if you want to work with multiple keyspaces in one session. Otherwise, you can only set_keysapce() once you get a node for operations like pycassa.
----- Original Message ----- From: "Dan Washusen" <d...@reactive.org> To: client-dev@cassandra.apache.org Sent: Tuesday, November 2, 2010 5:24:17 PM Subject: Question regarding Client.set_keyspace(String) Hey All, It looks like the Client.set_keyspace method does a server round trip to validate that the keyspace exists. Exhibit A: > InvalidRequestException(why:Keyspace does not exist) > > at >> org.apache.cassandra.thrift.Cassandra$set_keyspace_result.read(Cassandra.java:4816) > > at >> org.apache.cassandra.thrift.Cassandra$Client.recv_set_keyspace(Cassandra.java:451) > > at >> org.apache.cassandra.thrift.Cassandra$Client.set_keyspace(Cassandra.java:426) > > I was looking into making a connection pool that is independent of a keyspace. My thinking is that a connection pool is relatively expensive and if a user has more than one keyspace, it would be ideal to maintain a single pool for the cluster rather than one per keyspace. My plan was going to defer the Client.set_keyspace(String) call from the point that the connection is initialised, to the point that the connection is borrowed from the pool. However, if that call requires a server round trip it might do more harm that good... Two questions; 1. Does the call to Client.set_keyspace(String) really do a server round trip every time it's invoked? 2. If yes, is it really necessary? Cheers, Dan
