Auditing service method calls

We have a web application which obtains and manages data from a collection of services (technically not web service, but that is purely a transport-level implementation, and the service pattern remains the same). The thing is these service methods are "guarded" by layers of aspects sitting on top of the real methods. The aspects carry out common duties like authorization and auditing so that service methods do not concern themselves with these type of plumbing.

So if a user requested to view a particular record on the web page, the web app calls a service method to retrieve the data, and that request would be logged in the audit table. Now the issue is, if the user wishes to then edit/amend the record, the page would turn into amend mode with input controls. At this stage of postback, because these records are huge data items not good for storing in session, the retrieval method would be called again and that results in a second audit entry. Now if the user would save the changes, that is a third postback and the data would be loaded a third time to the web server because it needs to carry out some comparison checks for the changes before finally submitting for saving. That would result in a third audit entry for data retrieval, and then one audit entry for amendment.

Ideally, from the user's perspective of the audit trail, there should only be one log entry for record retrieval - the first time it was viewed. I am wondering what types of strategies or design pattern others have used in similar situations like this?

you may have your own reasons for such a design but the service interface seems quite chatty to me...

anyway, probably during the first retrieval the service would issue something like a session ID or number to the client? then the client, when performing its subsequent calls for editing/saving, would then pass this session ID back to the server. the server will recognise that the client has previously made a read request and as such would not write another log for the subsequent read operations.

The audit trail feature is implemented as an Aspect. The actual service code has no knowledge of the existence of the aspect. And the aspect is not designed to be intimatedly familiar with the nature of the underlying service methods it covers, thus has no additional ounce of business knowledge to make a decision whether to really log an audit entry or not.

hmm so if the logging feature/audit trail is an aspect that is oblivious of the actual usage patterns of the service, then we have to accept that it will really produce three log entries given your example. it's up to the person or the system viewing/analysing the log to notice that the three log entries are indeed part of only a single transaction.