If you share a repository instance with the Repository Add-in, you also share a transaction space with it. The Repository Add-in cooperates with the other add-ins with which it shares transaction space by adhering to these rules:
Thus, whenever your add-in needs to respond to an event by modifying the contents of the repository, it can bracket the modifications in a transaction, make the appropriate modifications, and complete the transaction.
That is, the Repository Add-in invokes the event sink method for the first registered add-in module, waits for that module to complete its processing in response to that event, and then invokes the event sink method for the next registered add-in module. Thus, when your add-in receives an event fired by the Repository Add-in, you can be confident that no other add-in module is currently responding to that event.
Your add-in module might not be the only module that shares a repository instance with the Repository Add-in; design your add-in to cooperate with other add-in modules. Thus, you should never return control to the Repository Add-in until your thread has finished responding to the event that the Repository Add-in fired. That is, do not return control to the Repository Add-in while you still have an active transaction in that repository instance.