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 13:51:16 GMT
On Sun, Jan 16, 2011 at 3:44 PM, Emmanuel L├ęcharny <elecharny@apache.org> wrote:
> 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.

+1 ... Absolutely!

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

Yeah that was a good improvisation to handle the lack of transaction atomicity.


> This was an issue we detected 4 years ago :
> https://issues.apache.org/jira/browse/DIRSERVER-840

IMHO we were very lucky that we had this opportunity. We're being as
creative as possible with the lack of transaction support. We just
need to bite the bullet and get this feature done once and for all.

>>> 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.
>
> <Snip/>
>
> 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 !

+1

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

That's up to you and this certainly is a less expensive way to
approach it. Everyone has their own way to approach things. My input
was optional, please disregard it.

Regards,
-- 
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