directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <>
Subject Re: Problem of JDBM being hard(impossible) to reconfigure once it is initialized
Date Thu, 17 May 2012 17:18:04 GMT
On Thu, May 17, 2012 at 2:37 AM, Göktürk Gezer <> wrote:
> 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.

If this read write lock is implemented at the level when nexus
interfaces the partitions, it might not be possible for a single
operation to see a consistent state of the server. This is because a
single operation might come down to nexus level several times.

1)One way to handle this would be to detect the configuration change
and abort the operation and retry it. This would be possible to do
with txns.

2) Another would be to use the RW lock in such a way that all
operations are quiesced before they begin executing within the server.
> 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


View raw message