...
This document describes design choices made regarding the ChangeLogService.
h2 Glossary
We need to define precisely some terms before starting to describe this service, to avoid any semantic confusion.
- Transaction : <to be done>
- Revision : <to be done>
- Event Log : <to be done>
- Transaction Log : <to be done>
- Journal : <to be done>
Protocol Changes
- Add the revisions attribute to the apache schema and enable addition of attribute to entries
- Add the Proxied Authorization Control (needed for replay)
- Add extended operation to take a snapshot
- Add extended operation to rollback to a previous revision
- Add capability to request specific versions of an attribute using the LDAP rev tag
Representing Changes (deltas)
...
To revert a sequence of forward (F) LDIFs { F0, F1, F2, F3 } the reverse (R) LDIF operations are applied in the opposite order { R3, R2, R1, R0 }. Some optimizations can be inferred from a sequence to make reverting faster. For example if F0 represents an Add operation and the other changes represent Modify operations on the same entry then only R0 can be applied instead of the R3->R0 sequence of reverse LDIFs. For the time being we just note that these optimizations are possible for implementing reversion capabilities.
Section | |||||
---|---|---|---|---|---|
|
The following page present the way reverse LDIF are generated : Generating reverse LDIF
Change Stores
Section | |||||||
---|---|---|---|---|---|---|---|
|
Simple
...
TaggableChangeLogStore Implementation
The first very basic functionality is to implement a basic loggertaggable change log without all the search capabilities. It has already been added , but some more elements need to be defined, like the way to start the logger turn versioning on and off, either via an LDAP extended request, or programmaticallywithout tracking of reverse LDIFs.
There is an existing page started by Ersin Er where you have a description of the existing ChangeLog interceptor :
Logging Subsystem
Semantics
We need to be able to start the logger, to stop it, to configure it, to select the requests, to select the users, etc. Here are a list of parameters we may want to set :
...
Parameter
...
Description
...
Mandatory
...
Logger name
...
The logger's name
...
...
Active
...
Activate or desactivate the log. Default to TRUE, and when set to FALSE, no other parameters should be given
...
Max Size
...
The maximum size of the log file
...
...
Saved Requests
...
The list of requests we want to save (AddRequest, DelRequest, for instance)
Default to ALL_REQUESTS
...
Saved Attribute
...
A list of attributes we want to store in the file. It may be associated with the
previous selection. '*' and '+' will be used for 'all users attribute' and 'all
operationnal attributes'
Default to '*'
...
Subentry
...
Define the subentry we want the logger to apply when logging. The user may want
to allow some users to log or not, or may define a set of entries which may be logged, etc.
Default to null : everything is loggable by default
...
Rotate
This implementation should keep things simple. Two files, forward.ldif, and reverse.ldif should be appended as changes occur. As one might suspect the forward.ldif stores in LDIF format the forward changes and is appended to at the tail of the file. The reverse.ldif file stores the reverse LDIF to revert the forward change and is appended to from the head of the file. This way a set of changes can be applied and reverted using these two files. Additional information such as the revision number, timestamp and the principalDn can be encoded within comments before the LDIF entry using implementation specific keys like the following:
Section | ||||||
---|---|---|---|---|---|---|
|
Tip | ||||
---|---|---|---|---|
| ||||
The best feature one can add to such an implementation is to store the log files in zipped form and insert new entries into them without having to expand the entire file. This however is the only feature worth adding to such a simple implementation. |
A separate file can be used to track snapshots. A simple properties file can be used for this where the key is the revision number for the snapshot tag and the value of the key is the description for the snapshot. This probably will not grow very large at all. Another file can be used to persist the current revision or a pointer could be kept on the head or tail to quickly read the REVISION information in the comments of the last entry added to either the forward or reverse LDIF file.
The change log should be a simple interceptor for the time being and can be configured via Spring or programmatically to be added to the interceptor chain. By default it should be disabled. Users can enable server versioning if they would like by uncommenting the interceptor.
Configuration information may be needed for the following possible settings:
- changeLogDirectory [path url] - where to put the changelog files
- compressChangeLog [boolean] - whether or not to keep the change log ldif files compressed
...
Define the way the file will be rotated : Daily, when exceeding a given size, after a certain period of time
...
Active
...
Activate or desactivate the log. Default to TRUE
...
...