I guess it depends what you mean by considerably. My initial thought was that, yes, this proposal would require CAS serialization scope to be per-key instead of the current per-table-per-key. That can only increase contention by a factor of at most the number of tables. Whether this is a considerable increase I guess depends on how many tables you have.
But actually, since C* only supports CAS conditions on a single table anyway, couldn't we just use that CF as a kind of coordinator? Then CAS is still per-key-per-CF so no additional contention is introduced. You don't get serial consistency between CAS conditions on different CFs but that's not something that's supported now anyway. You do get to include writes to other tables in your CAS batch and have the guarantee that if you observe the updated values in the coordinator CF then you also observe all the other mutations in any subsequent reads. This property is easily achieved by writing the CAS coordinator table mutation only after writing the mutations to other tables in PaxosState#commit. I think this would be very useful e.g. for an optimistic lock. Consider the bills example. The user is the aggregate root / partition key. Your CAS condition is on the users table (validating the optimistic lock version) but can include mutations to associated rows in other tables. These rows are logically part of the user aggregate by virtue of sharing the partition key. When, at the start of the application-level transaction, you read the optimistic lock you are guaranteed that subsequent reads to the other tables will return data at least as up-to-date as the lock. On 19 March 2014 05:19, Jonathan Ellis <jbel...@gmail.com> wrote: > No such plans. You'd increase contention across tables considerably. > > On Tue, Mar 18, 2014 at 11:31 PM, Ramon Nogueira <ra...@echophase.com> > wrote: > > Referring to this article on the recently added CAS features: > > http://www.datastax.com/dev/blog/cql-in-2-0-6 > > > > The new CAS batch feature is really cool; are there any plans to support > > CAS across column families within a batch? I think this would solve the > > same problems solved by the "static columns" feature in a less > mind-bending > > way. Also, it would allow you to keep the benefits of storing > > differently-typed data in different column families and have a > homogeneous > > logical "row type" per column family while still being able to CAS across > > all the data associated with a partition key. > > > > Considering the bills example from the article introducing the feature, > it > > strikes me as odd that the balance would be associated with the bills > table > > rather than the users table. Bills do not have a balance - users do. What > > if you wanted to use CAS to enforce other constraints when adding/editing > > bills e.g. that the balance is above some threshold calculated from other > > properties of the user? Yeah you could move all these into static columns > > of the bills table as well but that doesn't seem like a very coherent > data > > model. > > > > Another use case that I can't think of a way to handle with static > columns > > is as follows: suppose in the above example, you also kept a purchase > > history per user. If you wanted to keep the purchase history in sync with > > the bills table and the users table (for one user), you'd be out of luck. > > You'd have to squash everything into one table with some kind of type > token > > per CQL row that identifies what kind of data is stored in the row. Not > > very far down this road, you lose most of the benefits of CQL in the > first > > place. > > > > Having a look at the server code it seems (on a very naive first glance) > > that it wouldn't be too difficult to add CAS across column families. > > Indeed, a lot of it would seem to be just pulling out code that restricts > > the update to one CF in the first place, replacing ColumnFamily with > > RowMutation for the update. > > > > I'm not proposing CAS reads/conditions be cross-CF - I think this would > be > > substantially harder although also interesting. > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder, http://www.datastax.com > @spyced >
