directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <ayasel...@gmail.com>
Subject TXN WORK: advice needed on how to deail with logical caches
Date Mon, 17 Oct 2011 13:31:28 GMT
Hi all,
I am hoping to send a more detailed email as to where I am in the txn
implementation but I noticed I might hit a snag with regard to the
various logical caches we maintain.

Emmanuel is moving these caches out of interceptor but up until now
these caches were in interceptors. They map entry DN to a logical
value that is a predicate of the entry attributes. Currently I am
aware of notAlias and subentry cache(there could be more) as such
caches but it is not difficult to see people might add such cache in
their custom interceptors.

An example of the transactional execution we might have according to
the planned implementation is this:

R1, T1, T2 -> R1 is before T1 and T2 and should be isolated from them.
T1 is committed and T2 started after T1, so it should see the affects
of T1. Also changes of T1 are not reflected(flushed) to the underlying
partitions yet. Remeber that readers merge what they read from
partitions with the changes in the unflushed part of the txn log.

Now considers how we would make R1 and T2 see a consistent state of
notAlias and subentry cache. It seems to me the only possible way  is
to go ahead like we do with entries and index values: Update the cache
when the txn log is being flushed to the partitions  and when these
caches read, merge whatever we read with the txn log. However, each
separate cache requires a separate logic to handle this merge and i am
afraid it might complicated and slow as the number of such caches
increase. Especially expecting a custom cache implementer to get this
right seems dubious.

please let me know what you think

regards
Selcuk

Mime
View raw message