[Date Prev][Date Next]
Re: transaction logging
James Taylor wrote:
> I'm not clear of the benefit of putting this type of
> information in a database. Do you mean an LDAP directory?
I had not meant an LDAP directory of transactions (ahem, changes), but
the ideas from Mark's message seem very good. By using a different
back-end and keeping the changes in the LDAP directory we should be able
to get good results.
> Anyhow the notion of improved auditing has been bothering for
> a while but the approach I was thinking of was to modify the
> replication mechanism so that the transactions it uses are not
> always truncated away. I've been looking at the replication
> trim log functionality of slurpd but it may be more appropriate
> to have slapd write a second replog file dedicated for archive/auditing.
> Does this replog data suit your needs?
What do you think of the CHANGELOG approach with a separate back end and
possibly (I haven't finished reading the specs) some minor extensions
like new attributes?
> Will Ballantyne wrote:
> > I would like to put in some code to have transactions automatically
> > logged into a database rather than (or in addition to) a simple text
> > file for the ldbm back-end. I would like to store the date, id, a
> > unique serial number for the transaction, and the transaction data.
> > This approach will allow for better and more flexible replication later,
> > as well as better auditing.
> > Anyone have comments/objections to this approach?
> > --
> > Will Ballantyne GEMS Technical Architect
> > mailto:Will.Ballantyne@gems1.gov.bc.ca
> James Taylor e-mail: JMTaylor@slb.com
> Austin Computing Services phone: 1 512-331-3146
> Schlumberger Technologies, APC fax: 1 512-331-3059
> P.O. Box 200015 Austin, Tx. USA
Will Ballantyne GEMS Technical Architect