Concurrent schema creation/change strategy

[Magnus Vojbacke]

I have a lot of clients that will try to create the same schema (a keyspace 
with multiple tables) concurrently during application startup. The idea is that 
the first time the application starts, the clients will create the schema 
needed to run (create if not exists, etc...)

From what I’ve read, I think that Cassandra has support for concurrent schema 
creation and modification, but I assume there will be conflicts of some sort.


Is there any known strategy for handling this? Specifically considering 
conflicts.

In case of a conflict (e.g., two clients trying to create the exact same 
table), will the client call return with an error? (Datastax driver)

Would a plausible strategy be (for each client) 1) try to create the table, 2) 
examine any error coming back to determine if a conflict happened, 3) if 
conflict, move on to next table?

Or is it just better to add a separate step to create the schema at some point 
in time before the clients can be allowed to work (i.e. move schema creation 
out of the clients)?




Thanks
/Magnus

Clarification of property: storage_port

[Magnus Vojbacke]

I have questions regarding function and limitations of configurability of the 
property storage_port.

Function: What protocols and functions is storage_port used for? Am I right to 
believe that it is used for Gossip?

And more importantly: It seems to me that storage_port MUST be configured to be 
the same port for _all_ nodes in a cluster, is this correct? If not, can I 
configure it some how? I.e. can I configure node A to expect node B to use a 
specific storage_port? Or is this information propagated via Gossip? (Assuming 
that storage_port is not the gossip port itself)


Why would I want to configure different storage_ports? Function test 
environment with multiple nodes on the same hostname.

BR
/Magnus