[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Does ScopeKey need to maintain a sorted (in ScopeLevel.l

jason.greene@jboss.com do-not-reply at jboss.com
Thu Aug 6 11:08:34 EDT 2009


"alesj" wrote : "jason.greene at jboss.com" wrote : This class should *definitely* be immutable. 
  | I don't think this class was ever meant to me immutable,
  | otherwise there wouldn't be a freeze()/isFrozen() methods.
  | 
  | Afaik the idea is to have it mutable/dynamic to a certain point,
  | e.g. different layers add different scopes,
  | once we're past of allowing this additions we freeze it in order to be able to do deterministic lookups.
  | 

Right, I am saying that this class wants to be immutable and that the freeze/unfreeze is just a hack to make the current approach work . Its primary purpose is to represent a "path" to a scoped value, which is logically a fixed construct. As you mention, the mutation methods are just there to make assembling it easier, however this introduces a number or problems:


  | *  Collections need fixed keys, so now you have to "freeze" it somehow
  | * Since the object is passed between threads you need to synchronize state now. This ends up being very costly on a heavily accessed object, since even a non-contended lock still triggers a cpu fence, which typically involves waiting on particular cycle (wmb etc), and invalidates portions of the cpu cache. 
  | *  The usage is now error-prone. What if someone forgets to freeze? What if they don't check that it's frozen before they modify it?
  | 

There are other better ways to have easy assembly of a immutable class:

If all scope path elements are known, a varargs constructor / factory
   
  |  scopeKey =  new ScopeKey(serverScope, deploymentScope, classScope);
  | 

If the assembly process is done in a phased multi-participant process, than a chained-copy constructor can be used:


  | parentScopeKey = new ScopeKey(serverScope);
  | ....
  | childKey = new ScopeKey(parentScopeKey, deploymentScope, classScope)
  | 

If you prefer a even more flexible assembly approach, then a builder can be used:


  | builder = new ScopeKeyBuilder();
  | builder.add(parentScopeKey, deploymentScope, classScopeA);
  | builder.remove(classScopeA);
  | builder.add(classScopeB);
  | 
  | key = builder.toScopeKey();
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248510#4248510

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4248510



More information about the jboss-dev-forums mailing list