Hi,
some few comnts inline...
Le 5/7/12 11:04 AM, Selcuk AYA a écrit :
Hi All,
****CHANGES AFFECTING THE CURRENT CODE*********
*** The general motive is to implement a logical transaction layer
above partitions. This transaction layer keeps a log of logical
changes. It works above partitions and expects partitions to conform
to a certain data model and give some consistency guarantees:
1) Partitions should expose a MasterTable which
stores Entry objects. They also should expose the expected system
indices and can expose user indices. Master and Index tables are
basically (key, value) tables.
2) Supported modification operations on Master
and Index tables should be atomic
RdnIndex may be updated more than once when adding an entry, do to the
1/SubLevel indexes. If this break atomicity, then we have to deal with
that. (see below)
***Another goal in this effort was to move the operation execution
logic above partitions so that transactions could be implemented
independent of partitions with the above consistency guarantees.
Towards this goal, DefaultOperationExecutionManager has been
introduced. This mostly copies the logic in AbstractBTreePartition and
executes updates on master tables and indices using log edits rather
than direct updates on them. These log edits are then applied to
partitions using the atomic modifications on Master and Index tables
exposed by partitions. This class is where we really need to review
well to ensure things are OK.
Ok, will review this.
******MERGING********
- One and Sub level index removal will probably impact
DefaultOperationExecutionManager.
The question is to what extent these changes will impact the code.
- From emails, I understand the Index interface assuming UUID might be
a problem with the recent changes. Maybe this needs to be changed too.
Hmm, not sure. Moving to get rid of any other type to use UUID instead
is the right choice. All the indexes contains relation between a key and
some Entry's UUIDs (forward index), and between an UUID and some keys
(reverse index). The reverse index is used by the search engine.
Do you see any issue with that ?
Either before or both before and after the merge, we should run a test
with concurrent threads(read+write) and clear out any remaining
issues.
Ok.
*******TODO********
After the merge, I will work on implementing crash recovery part which
will complete the transactional layer changes.
Fine !
Great job !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
