On Tue, Nov 1, 2011 at 4:09 PM, Emmanuel Lecharny <firstname.lastname@example.org
> Hi !
> comments inline...
> On 11/1/11 12:19 PM, Selcuk AYA wrote:
>> thanks for the feedback! Please see inline:
>> I guess the xdbm-partition Maven module is now going to be pretty damn
>> or non-existent. Was this module destroyed and if not what actually
>> I think some util classes for tree based implementations remain there.
>> Also there some avl related classes.
> We can review this project and eventually move the remaining classes
>>>> The todo is the following:
>>>> *add changes to keep track of dn space changes.
>>>> *test txn manager services
>>>> *move the modification code path in AbstractBTreePartition in xdbm to
>>>> high up to core. Probably modifications should be done in
>>>> partitionNexus and partition nexus should handle preparing txn log
>>>> edits and wal them. The overall flow for modifications will be:
>>>> -execute interceptor chain
>>>> - handle txn abort, or conflict.
>>> Moving this into the PartitionNexus might not be a good idea but no
>>> for now we can move it later. Let me explain why:
>>> Eventually we're going to enable a root Partition with Partition nesting
>>> so when this happens the PartitionNexus will just be another nestable
>>> Partition since these will have to handle routing based on DN to other
>>> partitions residing/nested under it.
>>> I see two possible locations for this functionality:
>>> (1) Let the InterceptorChain itself handle this since it can demarcate
>>> start and end of calls into the chain with Txn begin and abort/commit
>>> It does this by making calls against the TxnManager which I guess is the
>>> entire facade for the transaction subsystem.
>>> (2) Handle Txn demarcation within the CoreSession. However this might not
>>> optimal due to the need to handle additional logic which might be
>>> for handling chain re-entry concerns.
>>> NOTE: I've not actually looked at the code after these major moves so my
>>> advice might not be very dependable. I will try to setup my environment
>>> get a better idea of these matters.
>>> However for the time being do whatever actually makes this thing work.
>>> follow an agile methodology. This thing is big. So let's get it working
>>> solid test coverage then we can actually look at shuffling things around
>>> optimal positions. Not saying what you've chosen is wrong ... it might
>>> present the need for some additional refactoring when other features
>>> need to be introduced.
>>> These are some of the biggest changes to the architecture to have taken
>>> place in years and you're doing a great job.
>> You are right for txn demarcation. I wrote it wrong in the email.
>> Demarcation has to be done either at defaultcoresession or
> OperationManager is probably the right place.
> For inner operations, I'm almost 100% sure they aren't modifiying anything
> (the only modification done as a inner operation has been removed a while
> ago : it was dealing with the addition of the ModifyTimeStamp and
> ModifiersName attribute, and it' snow done in the main operation). So we are
> safe if they are done in the current external transaction.
>> as for where to handle the change logic, as you mentioned we need a
>> place where all interceptor chain routes end up for modification and
>> ideally we should handle modification logic above partitions using
>> master table and index interfaces so that we have a common place to
>> prepare and apply txn log edits. PartitionNexus seems to fit this
>> requirement for now. If we add another layer above PartitionNexus
>> which can get master and index table from below layers and work with
>> them, we should be able to move the change logic up there.
>>>> *move xdbm-search to core as well. Making search transactional will
>>>> mostly be mostly mechanica after this point I think(hope). It should
>>>> just use the wrappers the txn manager provides for index, master and
>>>> cursors it gets from the partitions.
>>>> *handle caches various interceptors keep. I am thinking of handling
>>>> this with a common read-write lock.
>>> This was the latest issue for which I see some more threads. Will look at
>>> that as well.
>> This is the issue I talked you about briefly. These are mostly admin
>> caches that change infrequently and that are read mostly. The
>> difficulty with them is that they are not always entry caches. They
>> might map Dns to some logical property of the entry. A simple and good
>> example is notaliascache (whether we really need this is open to
>> debate but we have it now).
> This is a very interesting point. The notAliasCache is definitively
> questionable. The question though is to find a better way to deal with it.
> An option would be to not support alias (yes, I know, pretty drastic, but if
> it allows us to speed up the delivery of a production ready server, I think
> this would be a good tradeoff. Also note that once we have a solid base, we
> can reintroduce alias handling in a future version).
>> This maps a Dn to whether the entry is an
>> alias. If we followed the normal way of merging what is read from
>> partitions with the txn log, we would have to a way of merging what is
>> read from this notaliascache with the log. This is not very difficult
>> but as we have quite a number of these caches, having a separate merge
>> and update logic for each of them is a pain and error prone.
>> Instead, what I thought was to use a single system wide read-write
>> lock for these caches. Since they are read mostly, a txn might update
>> its lock to exclusive when it needs to change one of these caches and
>> might release it when it actually commits/aborts.
> We may start a new thread to discuss further those cache issues. We have
> many caches, for may different thinsg, and many different approaches to deal
> with the (MRU, EhCache, etc...). It's probably a good timing for clarifying
> this item...
> Emmanuel Lécharny