directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <>
Subject Re: TXN work update
Date Mon, 24 Oct 2011 18:40:57 GMT
On Mon, Oct 24, 2011 at 6:26 PM, Emmanuel Lecharny <> wrote:
> On 10/20/11 3:24 PM, Selcuk AYA wrote:
>> Continuing the previous incomplete email:)
>> Emmanuel wants to update the txns branch and I think it is a good time
>> to give a good status update. Following is what I have been doing and
>> the plan:
>> *Log Manager: A general log manager that can be used by txns as well.
>> Note that these logs are on disk. This is tested.
> I reviewed the LogManager (and the associated classes) this week-end and
> today. I committed a few fixes, no big errors. I have a few comments, not
> all of them are mandatory, some of them are suggestions :
> o Rename the Log class to TransactionLog, to avoid any confusion with the
> ChangeLog. Same for LogManager, LogFileManager, LogFlushManager.
this log is not just for txns. İt is a general logging solution. In
fact you can make the changelog use it instead of storing eveything in
memory. Still if you have a better suggestion, I can change the names.
> o The methods in an Interface don't need to be declared as public : they
> already are.
> o Don't forget to apply the ADS formatter : 2 lines between each methods, a
> newline before a return, etc…
OK. I think I will use the formatter to format it one final time
before check in after this time.
> o Don't add 'this.' when not necessary.
> o Always use { and } when writing a if/for/while/do
> o Try to avoid inner classes, except to hide the inner class behavior
I sometimes use them to logically group data used together but
strongly tied to a class. and I think it makes sense to use them in
that way.
> o Don't declare an interface into another one
> o LogFileManager should be moved to core-api
> o LogScannerInterval should be moved to core-api
the two above are internal interfaces that are used internally. I
thought core-api has public interfaces.
> o The LogFileRecords class might better be an interface ?
fine as it is I think. This just groups data related to internal
format of the log implementation. NOt every log implementation has to
have them.
> o fields in classes must be private or protected
> o Transaction should be moved to core-api
> o TxnManagerInternal should be moved to core-api
See comment for LogFileManager and LogScannerInternal
> o Arrays are always initialized to the default init value of their
> components (ie, 0x00 for bytes) : no need to initialize them
> Many of this points may be discussed further.
> Otherwise, I'll continue to explore the code base to understand how it
> works.
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny

View raw message