I have some questions...
On May 17, 2012 8:18 PM, "Selcuk AYA" <email@example.com> wrote:
> On Thu, May 17, 2012 at 2:37 AM, Göktürk Gezer <firstname.lastname@example.org> 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.
Are these multiple nexus level accesses are coming from interceptors?
Is it inconsistent or inconvenient. I mean when some operation O access the partition at X and Y times, if we for example update user attribute indexes between X and Y, is there a possibility for Y to fail? Or is there any configuration change type which can cause Y to fail?> 1)One way to handle this would be to detect the configuration changeYeah absolutely.
> and abort the operation and retry it. This would be possible to do
> with txns.I don't know right know if there is a spot where I can put locks to ensure this behaviour. I'll look into that.
> 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