Moved transaction creation to the TrustList Open method.

This change caught me by surprise now. The description for transactions made perfectly sense to me. Also the CloseAndUpdate() method looks like a perfect equivalent to the UpdateCertificate() method and therefore hints that it is responsible to create a transaction. This makes also sense, because only CloseAndUpdate() has all information required to validate the new data before creating a transaction for it - like UpdateCertificate() is able to do for Application Instance Certificates.

Moving the transaction creation to the Open() method also introduces additional complexity: what shall happen to the transaction if validation fails in CloseAndUpdate() or the Close() method is called? These situations basically mean that no changes are to be applied to the opened trust list. But the server cannot blindly discard the new transaction now because there might be other changes already scheduled with it. This looks rather complex and also has to be specified where the most obvious change to me would have been to just adapt the diagram to the described behaviour.

Needed to address the race condition issue you mentioned in another issue.

Also, the new file based update mechanism which will be the preferred mechanism moving forward effectively requires the same thing.

Transactions exist based on the assumption that changes need to applied all at once or not all.

OK that's fine for me. This seems to keep the complexity relatively low. I assume that the following cases shall then discard an open transaction:

• calling "Close()" on a TrustList opened for writing
• any failure when calling "CloseAndUpdate()" on a TrustList opened for writing
• any failure when calling "UpdateCertificate()"

Fixed by moving transaction creation to the Open().

The CancelChanges method is used to clear up any transaction.
If it is not called, transactions close if the Session is times out.

Agreed to changes in web meeting.