directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Some more thoughts about AP handling
Date Sun, 16 Jan 2011 12:14:58 GMT
On Sun, Jan 16, 2011 at 1:23 PM, Emmanuel L├ęcharny <elecharny@apache.org> wrote:
> On 1/16/11 11:52 AM, Alex Karasulu wrote:

...

>>> - 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.

Wonderful if we can do that, even better.

>>> - 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 present.

Yes this is what is drawing me closer to the option of integrating
this feature directly into the chain. The interactions here are
getting complicated, and we may need to get a bit explicit about this
capability by directly building it into the chain.

This way there are no worries about where in the chain anything goes.
I don't want another interceptor even thinking about messing with how
this mechanism works. It should not be something that is left open to
tampering by even an Interceptor implementor.

We can create interfaces where if users want to replace the TxNManager
or it's component they can do so. But the relationship it has in the
chain is an explicit contract not left to any interpretation or
ambiguity.

> We can discuss those points after M1.

Sure. I like to think a couple steps ahead in case we can inject into
M1 things that help rather than make these features put into M2 more
difficult.

I agree 100% with the one step at a time approach: dropping some hints
so people can chew on these thoughts over time.

>> 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).

No one would disagree with these points. We do need all ACID features
and I feel we're not that far from reaching them.

> 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.

Isolation is non-existant allowing for dirty reads. We can solve this
issue though. It's going to take time and some evolution.

> 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).

SPs and Triggers will present these same issues.

AP is the first time we seriously hit a wall with this because we're
getting to complex scenarios that are requiring these multiple updates
to happen in an atomic way. There will be more cases in the future I'm
almost certain of this.

> 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.

Actually this sounds a lot more difficult than it will be. We also
have a lot of the machinery available. We need txn log and some other
things.

However what I recommend is to do this in steps. Does not have to be
fully implemented in a single milestone release. We can just erect the
scaffolding and have the rest of the system using the API.

Across other milestones we can start filling in the implementation
with minimal impact to ADS SPI users.

>>>
>>> - 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.

You and I both know we can set features to be in milestones and it all
shifts. I seldom works for us. Let's be a little bit more flexible but
make sure we're pumping stuff out with milestones.

It would be nice if we got into a groove every 2-3 weeks to pump out
another milestone release even if features are just partially
implemented.

If [A|S]PI's are solid we can introduce new implementation elements
with the minimum of disruption to our users.

>>>
>>> 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.

+1 there. Nice to have users gradually getting into the groove of
using the LDAP based configuration. We get more feedback and can
incorporate that into upcoming milestone releases.

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.

Absolutely, shifting APIs sucks for us (since we use it) but sucks
even more for our users. The milestone scheme is great though, since
users know that they're promised API stability with RC1. Still though
we can take certain steps to make API shifts as painless as possible,
like by getting these interfaces carved out, released and continuing
implementation enhancements in the background.

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Mime
View raw message