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

[adrian@jboss.org]

"smarlow at redhat.com" wrote : "adrian at jboss.org" wrote : 
  |   | The brain dead part is that it gets used at runtime in the BasicMetaDataRepository
  |   | as the key to a map which it then freezes to avoid mutablity.
  |   | The issue being that you still could incur contention because
  |   | of the synchronization on the scopes within the ScopeKey traversed in equals()/hashCode().
  |   | 
  | 
  | I assume you mean in the current implementation (even with freeze, synchronization is needed).  With the proposed changes, we don't need the synchronization on the scopes within the (immutable) ScopeKey.  
  | 

BACKWARDS COMPATIBILITY

I'm saying immutability breaks backwards compatibility (in our code and in other
code which might not even have been written yet but could get written against the
existing api in the released jboss5/mc binaries).

That's because the ScopeKey is used as a builder.

Our main use case is just to build a APPLICATION/DEPLOYMENT scope 
from the "Default Scope" and an INSTANCE/CLASS scope on top a DEPLOYMENT.

This is done with a clone() and addScope().

So if you clone it or use some more optimized object in the MDR itself then this
synchronization is not required.

REASON FOR SCOPEKEY BEING MUTABLE

You do need something like the ScopeKey being mutable until the last minute
because things like the CLASS scope may not be known until the bean instance
is constructed from a factory. Only then do you know the class.

There was also an additional (unimplemented or at least unused) requirement 
to allow services to add extra scopes. e.g. an EJB could add a CLUSTER scope to get 
shared clustered metadata.
Or similarly allowing a SUBSYSTEM scope for shared defaults, e.g. SUBSYSTEM=EJB
So each stage of the deployment can modify the full MDR scope until it gets registered.

YOUR SOLUTION VS MY SOLUTION

Changing all the other api, e.g. DeploymentUnit, KernelScopeInfo, etc.
to make this "mutable scope holder" some other class would be a lot more effort
(besides breaking existing - or even still to be written - use cases). 

It would be better to just the leave the ScopeKey as the builder and optimize the
runtime in one of the ways I suggested (or maybe some other way you can think of?).

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

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