David Lloyd wrote: > Paul Robinson wrote: > > David, > > David Lloyd wrote: > > > > OK I will attempt to answer as many questions as I can. > > > [Q] Is it correct that the audit should contain the update (and it's outcome), even if the transaction failed and also in the presence of a crash? > > Starting off with the tough ones I see. :) > > > > Currently our audit requirements are met by using syslog-style remote logging, which is done in a very ad-hoc manner (i.e. without sensitivity to crashes).  It will be difficult, regardless of the answer to this question, to both meet the remote log requirement as well as dealing with the possibility of crashing.  AFAIK there is no way to log to syslog transactionally. > > > > Ignoring that problem though, my feeling is that we are only required to Audit (with a capital A) changes that were successfully made, but we do want to at least locally log (in a human-readable fashion) failures as well. > > Given the limitations of the syslog-style logging, is it sufficient to simply log successful operations immediately after they occur? This raises a number of possible issues: > > * There's a window between the transaction completing and the audit being written. A failure here would result in a un-audited successful action. > Yeah it's a tradeoff between logging things before the transaction is committed, and potentially losing stuff.  And syslog itself is not exactly super-robust.  But I think that the limitations were known and accepted when this solution was designed. > * Some transactions will be completed by the recovery manager. I don't think the audit would be written for these under the current solution. > > The problem with these two issues is that I don't think there is an easy way for the user to know that there are some potentially missing entries. We could solve this by always logging the intent of the transaction to the audit prior to beginning it. Then by taking all 'intent' entries without a corresponding 'outcome' entry, you get a list of items to investigate. With this approach you would also need to log failures, in order to ensure that the 'outcome 'is always present. > > How important is it, that the audit be complete? If we can't provide strong enough guarantees, maybe we need to consider using a transactional audit? I think it's pretty important that it's complete, and we probably will want to look into a real transactional audit at some point (not today though as the current solution was deemed good enough by its implementers).