directory-dev mailing list archives

Re: Problem of JDBM being hard(impossible) to reconfigure once it is initialized

Date

Thu, 17 May 2012 09:37:35 GMT

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