Hi,
I'd like to inform you about the current status, and the problem I'm
currently facing.
So far, I was able to implement the AP handling using some kind of
revision numbers (I think I have explained extensively how it works
those past 2 months). This approach is quite promising, as it allows us
to avoid a costly update of the backend when some Subentries are
modified. The Add, Delete, Search and Lookup operations are implemented,
and part of the rename operation.
Today, as I was working on the rename operation, fixing a few issues
here and there (SubentryCache weren't thread safe), I faced some dire
issue : the ChangeLog mechanism came into the mechanism like a stick in
the wheels. Let me explain.
When you apply some modification on some entry, we compute the revert
operation in the ChangeLog Interceptor, in order to be able to apply it
when reversing the operations. It works wonderfully in most of the case,
except in some corner cases we are aware of (typically, when adding an
entry, creating an alias on this added entry, removing the entry - and
then the alias is pending, but this is legal - and removing the alias.
If we revert these 4 operations, the addition of the pending alias will
not be accepted).
Now, I have another issue, which is quite similar :
- I add a SAP
- I add an entry
- I add a subentry associated with the SAP which select the entry with a
CollectiveAttribute role
- I do a lookup o the entry, which modify the entry to point on the subentry
So far, so good. Now, when the revert operation starts, it does :
- remove the subentry, leaving the entry with a reference to the removed
subentry
- try to remove the entry, which does a read of the full entry, which
tries to add the CollectiveAttribute using the reference to the removed
subentry, leading to a NPE.
Sounds not very good, isn't it?
I still have options :
- when we delete the entry, we do a lookup in the eagerlyPopulateFields,
which tries to inject the collectiveAttribute into the entry : why ? I
see no reason to do such a thing (I'm not sure either that most of the
interceptors the lookup is going through are to be executed. To be
double checked)
- I can add some extra checks in the CollectiveATtributes to deal with
this specific case, ie if the reference to a subentry exists and if the
entrySeqNumber is above its AP seqNumber, then I don't update the
CollectivAttribute (yuk :/)
- ultimately, we can also change completely our startegy and decide to
update all the entries immediately when doing an operation on a subentry.
I will investigate the first option atm, which sounds the most
productive, but still, we may have to consider some more global
modification.
I will keep you updated.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
