Hi,

To let all of us think in a way that is compatible with new design. I felt like i have to share some basic knowledge of how it works.

Every entry in config partition is tried to be instantiated by component-hub. There are some things that need to be satisfied to be able to instantiate an entry into an actual object, like its complex typed dependencies(component or collection) must be instantiated first and of course the ComponentFactory owning that entry must be present in OSGI. These aspects and some more are tracked by ComponentHub and the corresponding DirectoryComponent reference is activated and deactivated in regard.

DirectoryComponent is an base type for handling components in and outside the ComponentHub. It's a container of information for component containing type,configuration,nature and runtime attachments of component.

To access these DirectoryComponent references in ComponentHub one must register AbstractHubClient implementation with the ComponentHub. For example:

InterceptorHubClient ic;
hub.registerHubClient(ic, Interceptor.class);

after this registration, 'ic' reference will begin receiving events of DirectoryComponent wrappers of Interceptor implementations as they're activated and deactivated by ComponentHub.

Then some HubClient can call DirectoryComponent.getRuntime().getPojo() method to access actual Object, cast it to Interceptor and use it as normal Interceptor. Casting will succeed, which is ensured by ComponentHub.

So with these basic knowledges in mind. i've come up with two ideas in mind, !!! again, these are in case if it's not possible to handle reconfigurations in JdbmPartition concurrently. !!!

1- Currently AbstractHubClient references are used to track only ACTIVATED,DEACTIVATED and DEACTIVATING events for DirectoryComponents. Only special event here is DEACTIVATING which is sent when it is possible to abort deactivation of component, for example when user is deleting component's corresponding entry in DIT, so HubClient can abort this deletion if it's going to put server in inconsistent configuration.

We can add two more event here, RECONFIGURING and RECONFIGURED. So with this event in pocket, HubClient for Partition.class (which will be heavily connected with PartitionNexus, or we can implement it right inside PartitionNexus) can choose to detach reconfiguring Partition from PartitionNexus and attach it again when UPDATED event is received. While HubClient implementation for Partition.class works that way, we can just ignore UPDATE* events in HubClient for Interceptor.class

Pros:
 * We can keep accesses to components as native Object references
Cons:
 * We have to add some more methods in PartitionNexus to deactivate and activate Partitions without initializing them at activation.

2- We insert an additional RWLock into every DirectoryComponent. And keep components as DirectoryComponent in code(DirectoryService and PartitionNexus mainly). So when PartitionNexus access one of its Partition reference to proxy some operation, it first locks on read-mode on its wrapping DirectoryComponent. And all reconfigurations on ComponentHub side locks on write-mode.

Pros:
 * No attachment and detachment of components(Partitions) from their holder.
Cons:
 * We must keep DirectoryComponent reference rather than their native reference type to access their lock.(Actually in HubClient for Partition.class, we can embed this lock into JdbmPartition reference once we got its DirectoryComponent reference, and we just change PartitionNexus to retrieve Lock objects of AbstractBTreePartition references just before invoking their operations. So this approach invalidated the need of keeping DirectoryComponent reference with this approach, just with a minimal cost to change AbstractBTreePartition code to have an additional RWLock object)


Thoughts?

Regards,
Gokturk