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 13:44:31 GMT
On 1/16/11 1:14 PM, Alex Karasulu wrote:
>> 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.

Very true. This is an area we have to investigate, as it's more a 
prototype right now than a completed feature.
> 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.
FTR, we fixed some ACID issues last year, when we reviewed all the 
operations. The operational attributes were added after the entry was 
stored in the
backend, leading to a potential breakage. Now, the op attrs are 
injecting in the entry *before* being injected in the backend.

This was an issue we detected 4 years ago :

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

Right now, before discussing what will be in M7, I think the best is to 
get M1 out with OSGi, some refactoring in shared, and as few possible 
thing as possible !

Then we will be able to start discussing about what is in M2, then in 
M3, etc... Let's not anticipate on the problem we will face anyway 
before facing them :)

Emmanuel L├ęcharny

View raw message