Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of ayaselcuk@gmail.com
 designates 209.85.213.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKjwzkqnvczXUUyAKMV4XDX=GdKiYvSV0kKnvoUYuJZkRUAU5Q@mail.gmail.com>
References: 
 <CAKjwzko_FBBh5ag9L3FS_K6H2x7B0OXtoED7uLNMMHbXsUwu9A@mail.gmail.com>
	<CAG8=FRi_S+LxsTdocRwrUTVEw3WNMyQtK1+8kJOdB=TigBE-mQ@mail.gmail.com>
	<CAKjwzkqnvczXUUyAKMV4XDX=GdKiYvSV0kKnvoUYuJZkRUAU5Q@mail.gmail.com>
Date: Thu, 17 May 2012 10:18:04 -0700
Message-ID: 
 <CALhXAG2=ro94Kv6vW+SG480zaKSJsx+8rT9LnNsfUTXWJctShg@mail.gmail.com>
Subject: Re: Problem of JDBM being hard(impossible) to reconfigure once it is
 initialized
From: Selcuk AYA <ayaselcuk@gmail.com>
To: Apache Directory Developers List <dev@directory.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, May 17, 2012 at 2:37 AM, G=F6kt=FCrk Gezer <gokturk.gezer@gmail.com=
> wrote:
> Hi,
>
> To let all of us think in a way that is compatible with new design. I fel=
t
> 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. Th=
ese
> 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 containin=
g
> 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 norm=
al
> Interceptor. Casting will succeed, which is ensured by ComponentHub.
>
> So with these basic knowledges in mind. i've come up with two ideas in mi=
nd,
> !!! again, these are in case if it's not possible to handle reconfigurati=
ons
> in JdbmPartition concurrently. !!!
>
> 1- Currently AbstractHubClient references are used to track only
> ACTIVATED,DEACTIVATED and DEACTIVATING events for DirectoryComponents. On=
ly
> 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 delet=
ion
> if it's going to put server in inconsistent configuration.
>
> We can add two more event here, RECONFIGURING and RECONFIGURED. So with t=
his
> 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:
> =A0* We can keep accesses to components as native Object references
> Cons:
> =A0* 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 PartitionNe=
xus
> 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 o=
n
> 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:
> =A0* No attachment and detachment of components(Partitions) from their ho=
lder.
> Cons:
> =A0* 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 t=
o
> retrieve Lock objects of AbstractBTreePartition references just before
> invoking their operations. So this approach invalidated the need of keepi=
ng
> DirectoryComponent reference with this approach, just with a minimal cost=
 to
> change AbstractBTreePartition code to have an additional RWLock object)
>
>
> Thoughts?
>
> Regards,
> Gokturk

thanks
Selcuk