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

Christopher Tubbs commented on ACCUMULO-4050:
---------------------------------------------

bq. ... And these containers could be merged together ... Or, would the 
container be abstracting this hierarchy away?

The container abstracts the dynamic configuration for a single scope. The 
snapshot represents the actual configuration pairs (at a single point in time), 
providing all the normal conf getters from an immutable source.

It's not so much that the containers are merged... it's the snapshots they 
*contain* are merged to form the view of the config for the caller.

Let me try to give an example using only part of the hierarchy, using table T, 
and namespace N:

* T config is stored in {{/path/to/tables/T/conf}}
* N config is stored in {{/path/to/namespaces/N/conf}}

* {{tConfContainer = new TableConfContainer(T)}} is the "container" for T's 
configuration
* {{nConfContainer = new NamespaceConfContainer(N)}} is the "container" for N's 
configuration

When the caller needs the per-table configuration for T, it does something like:
{code:java}
TableConfigurationSnapshot tableConf = 
ServerConfigurationFactory.getTableConfigurationSnapshot(T);
{code}

At this point, {{ServerConfigurationFactory}} constructs a new 
TableConfigurationSnapshot something like this:

{code:java}
public getTableConfigurationSnapshot(Table T) {
  return new TableConfigurationSnapshot(tConfContainer.getSnapshot(), 
nConfContainer.getSnapshot());
}
{code}

Now, {{TableConfigurationSnapshot}} provides an immutable hierarchical view the 
chain of snapshots.


> Serialize table configs into a single ZK node
> ---------------------------------------------
>
>                 Key: ACCUMULO-4050
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4050
>             Project: Accumulo
>          Issue Type: Sub-task
>            Reporter: Christopher Tubbs
>             Fix For: 2.0.0
>
>
> Use a single ZK node to store table configs, rather than split across 
> multiple configs. This should make it easier to implement atomic changes to 
> the configuration, and should simplify reading loading/saving configuration 
> from/to ZooKeeper.



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

Reply via email to