cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9425) Make node-local schema fully immutable
Date Wed, 18 Jan 2017 14:54:26 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828214#comment-15828214
] 

Aleksey Yeschenko commented on CASSANDRA-9425:
----------------------------------------------

bq. Well, actually, your motivations on this are lost on me. I'm certainly not pretending
that optimization was the most important thing ever, but as mentioned in the original ticket
it did show up in some profiling and the "optimization" was beyond tiny and entirely encapsulated
within the class. As an aside, also not a fan of manually writting hashcode() methods when
the simpler Objects.hashcode() can be and was used.

I do want to get rid of the auth object in my metadata code because conceptually I don't want
metadata to be aware of auth. But once you get rid of the field, memoising the hash code in
the {{DataResource}} object itself becomes meaningless, so you need to 'fix' {{DataResource.hashCode()}}
properly, too (in that JIRA, you claimed that the allocation of the array for varargs was
an issue; in reality it shouldn't be - once that code gets hot enough, it should be stack
allocated, but I have no flight recorder runs to prove it). So should some of the allocated
{{DataResource}} objects. TL;DR: I don't like this part of the CASSANDRA-10410 ticket, but
I don't care enough about this to fight it, so I can revert my change.

> Make node-local schema fully immutable
> --------------------------------------
>
>                 Key: CASSANDRA-9425
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9425
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Aleksey Yeschenko
>            Assignee: Aleksey Yeschenko
>             Fix For: 4.0
>
>
> The way we handle schema changes currently is inherently racy.
> All of our {{SchemaAlteringStatement}} s perform validation on a schema state that's
won't necessarily be there when the statement gets executed and mutates schema.
> We should make all the *Metadata classes ({{KeyspaceMetadata, TableMetadata}}, {{ColumnMetadata}},
immutable, and local schema persistently snapshottable, with a single top-level {{AtomicReference}}
to the current snapshot. Have DDL statements perform validation and transformation on the
same state.
> In pseudo-code, think
> {code}
> public interface DDLStatement
> {
>     /**
>      * Validates that the DDL statement can be applied to the provided schema snapshot.
>      *
>      * @param schema snapshot of schema before executing CREATE KEYSPACE
>      */
>     void validate(SchemaSnapshot schema);
>  
>     /**
>      * Applies the DDL statement to the provided schema snapshot.
>      * Implies that validate() has already been called on the provided snapshot.
>      *
>      * @param schema snapshot of schema before executing the statement
>      * @return snapshot of schema as it would be after executing the statement
>      */
>     SchemaSnapshot transform(SchemaSnapshot schema);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message