directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: Some more thoughts about AP handling
Date Sun, 16 Jan 2011 11:23:56 GMT
On 1/16/11 11:52 AM, Alex Karasulu wrote:
> - first make the current trunk working. We have an issue as the subentries
>> are not read back when the server is stopped, so we can't have the ACI
>> working again. That's a stupid error which can be fixed easily.

I *think* I have fixed the issue last night (there was a bad removal in 
the APCache).

I will conduct some more thorough tests this afternoon.

>> - implement #1 : no more modifications made on the backend, all is evaluated
>> on the fly
> After this I suggest we clean up shared, and get Studio depending
> directly on it's OSGi bundles, and do some M1 releases. This can be
> the first 2-3 week sprint.

+1. But I think it can be even faster.

>> - have a TransactionManager (TM) implemented
> Before this point we can cleanup some of the ADS SPIs and then
> refactor the interceptor chain making transaction management a core
> function of the chain rather than an interceptor. There should be no
> degrees of freedom with this feature since it's a must have.
This is a complex situation. We all agree that it's a core function, and 
should always be present and at the end of the chain if it remains an 
interceptor. But this is a larger problem : we have other interceptors 
in the chain that must be at specific positions and should always be 

We can discuss those points after M1.
> The two journals (CL&  Journal) should be consolidated into a single
> log even if two separate tactics are used inside the same component.
> This means the CL and Journal are merged and no longer managed using
> Interceptors. There are other cleanup we can do to simplify the chain
> as well.
+1 for merging them.
> TxN management although not imparting ACID capabilities in this round,
> should be clear, clean, and simple with all scaffolding erected so the
> API can be properly used. Slowly we can then add all the
> implementation details needed to implement all ACID features with
> coming milestones.

Right now, LDAP servers are just supposed to guarantee atomicity, 
Consistency and Durability. As all the operations are supposed to affect 
only *one* entry, this leads LDAP implementation to implement Isolation 
as well (so it's full ACID).

Now, this is true for updates, not for searches which span over more 
than one entry, which means the entries you get back may not be fresh 
when you want to use them.

However, ADS has a few issues with ACIDity when it comes to manage APs, 
as we update more than one entry when injecting a subentry. (I don't 
think there are other oparations that need more than one update, but 
OTOH, a lot of update operations do a lookup before doing a write).

This is the reason we need a TM. Note that if we don't update the 
entries when injecting a subentry, we are safe (this is option #1, btw)
> Then a set of M2 releases can be made.
I would move that for M3 instead. We don't have a lot of background on 
TM atm.
>> - add support for IAPs
>> - once all those pieces have been added, then we can move to #3
> This can be an M3 release.
M3 release could contain the TM, and a M4 a complete ACID implementation 
of APs, where we update entries instead of evaluating them on the fly.
>> Of course, we have other things on our plate which can be done in parallel,
>> like refactoring the APIs.
> There will probably be incremental steps here. For M1 we can do what
> seems reasonable and clear to us. Like a base line push, but I am sure
> we'll begin to see more refactorings condense as we progress on each
> sprint.

In fact, having a M1 fast could be a good first step, considering that 
it will simply expose the current trunk and the new configuration 
system. There are some documentation to be written in this area, and 
it's hard to do so on a moving target. Also for studio 2.0-M1, which 
include a plugin to manage ADS 2.0 config, having a stable release of 
ADS would be a great thing.

Emmanuel L├ęcharny

View raw message