belliottsmith commented on code in PR #33: URL: https://github.com/apache/cassandra-accord/pull/33#discussion_r1099873518
########## accord-core/src/main/java/accord/local/ImmutableState.java: ########## @@ -0,0 +1,202 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package accord.local; + +/** + * Since metadata instances are immutable, there can be several copies floating around in memory, all but one + * of which is stale. This can lead to difficult to diagnose bugs, especially when an implementation side cache + * is involved. + * The ImmutableState base class defines the various lifecycle stage and helps restrict what the user does with it, + * with the goal or throwing an exception as soon as an illegal usage occurs, instead of after. + * + * An up to date instances can have one of 2 statuses, DORMANT or ACTIVE. An instance is only ACTIVE in the time + * between when the safe store for it's current operation is created, and closed, and is otherwise marked DORMANT. + * While DORMANT, it cannot be read from or updated. This is to help detect leaked instances being read from or + * updated when they shouldn't be. + * + * Once an update has created a superseding instance, the original instance is marked SUPERSEDED. It can then be + * marked CLEANING_UP, during which time its fields can be read to assist in determining what has been updated. + * From CLEANING_UP, an instance can be marked INVALIDATED to indicate that any access is illegal. An instance + * marked SUPERSEDED can also go directly to INVALIDATED, in the case of intermediate updates. + */ +public abstract class ImmutableState Review Comment: > The only scenario where I think a stale command would be useful is in the construction of an update A stale command _could_ also be useful in listeners when deciding what action to take because of a delta, though I think today we probably don't require it. We will probably need to separately track/expose the state machine types, though, as they can change within the same reference. Perhaps we can just call them an `UnsafeCommand` to distinguish them? >What about making Command more of a state container? Something like AtomicReference, where there is no more than one instance in memory for a given Command/CommandStore I think this would be an immediate improvement for sure. I think the only difference between our proposals is that I think it would be better to _hide_ this reference (let's call it an `UnsafeCommandRef`), as exposing it directly potentially masks some bugs. Since we expect there to be only one active operation touching the latest value at once, if the `SafeCommand` we pass around internally references an `UnsafeCommandRef` and _also_ the `UnsafeCommand` that was pointed to _when the `SafeCommand` was constructed_, then on each access we can validate that nobody has changed the underlying value, and fail an assertion if they have. Another option is to have CAS semantics, but this only catches erroneous updates and potentially makes our control flow a bit more complicated. Not committing 100% to my proposed nomenclature, feels like we can maybe do better. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
