You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2011/03/08 18:00:00 UTC

[jira] Resolved: (CASSANDRA-1335) Add Consistency Level for Schema Creation Operations

     [ https://issues.apache.org/jira/browse/CASSANDRA-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis resolved CASSANDRA-1335.
---------------------------------------

    Resolution: Won't Fix

ConsistencyLevel inherently can't be applied to schema management, since CL deals w/ replication factor but schema changes affect each node in the cluster.  But see CASSANDRA-2287 for what we can do.

> Add Consistency Level for Schema Creation Operations
> ----------------------------------------------------
>
>                 Key: CASSANDRA-1335
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1335
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.7 beta 1
>         Environment: CentOS 5.2
> Trunc
>            Reporter: Arya Goudarzi
>
> Currently when applications create Keyspaces and CFs dynamically, user at application level has to make 2-3 calls to Cassandra to verify consistency of the schema as follows for example:
> 1. system_add_column_family
> 2. check_schema_agreement (will return a checksum of schema definitions and the nodes agreeing on them, user has to count the result to see if there is one checksum with all nodes meaning agreed or multiple checksums which means disagreed;)
> With clusters that have many application servers talking to them with high concurrency, it is possible for result from check_schema_agreement to be inconsistent in different nodes causing application misunderstanding of schema since application is no aware how the schema checksum is calculated. 
> One solution that I've thought to add at the application level is to create locks using memcache on CF and KS creation operations so that many clients don't collide. However, I have to loop through check_schema_agreement and store the state and also do describe_keyspace, hence a 3rd call, since I am not sure how the checksum is calculated in order to verify I am not asking another client to create the same CF or KS. This potentially could fall into infinit loop if client calls fail and I have to bind to an application level timeout detection to I don't loop forever. 
> I think it would highly make sense to have something like ConsistencyLevel added to schema creation operation to avoid users having to implement their locking and validation at their application level.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira