Applications cannot keep per-document data in global or static variables. This includes AcDbDatabase objects, AcDbObject objects, AcDbObjectId values, header variable values, document variable values, selection sets, and other document-specific information. Any occurrence of per-document data in global and static variables might be corrupted if your application is run in multiple concurrent edit sessions.
To avoid corruption of data, you can encapsulate command behavior and data into classes. An instance of the class can be instantiated for each call to the command. As the command acquires document-specific data, it keeps its own per-instance copies of that data.
Another solution is to encapsulate all of the global and static data into a structure or class. A copy of the data is instantiated for each document. A local pointer to the appropriate instance is set at each entry point in the application. The local pointer is then used to access the per-document data. Use the documentActivated() reactor to switch between instances of the encapsulated data.
You can create the per-document data on an as-needed basis, or create it when the application is first loaded. If created on an as-needed basis, as the application's registered commands or reactors are called, the current document is determined and a query is made to get the document's data. If it is not found, it is created at that time.
To create the per-document data when the application is first loaded, use an AcApDocumentIterator in the AcRx::kInitAppMsg handler to get a list of all open documents. Then use AcApDocManagerReactor::documentCreated() to know when to create additional per-document data for documents opened after the application is loaded.
Whichever method is used to allocate the per-document data, the application must use the AcApDocManagerReactor::documentToBeDestroyed() reactor in order to know when to delete the data. Applications should also delete the remaining data during the AcRx::kUnloadAppMsg handler.