CDR Tickets

I don't think this falls under the category of "good bug" because it would mean you could be using (for example) the wrong DTDs for local validation. We need to ensure that this can't happen. 😛

The solution is to add the following code to the loader program:
 

CreateMutexA(0, FALSE, "Local\\$cdrloader$");
if(GetLastError() == ERROR_ALREADY_EXISTS) {
    // display message and exit
}

Hmm, it's not as simple as that. The problem is that the loader process exits after XMetaL is launched, which would remove the mutex it created, allowing another instance of the loader to launch a second XMetaL process. Creating a more permanent lock runs the risk that code to clean up that lock when XMetaL is closed might never run (for example, if XMetaL crashes, or the user has to kill the process forcibly), leaving the machine in a state where XMetaL can't be run until the lock is removed by some other mechanism. We could build a separate tool which the user could execute for that purpose, but that's a clumsy solution. A better approach might be to have the DLL create a lock which the loader checks. If the lock is already in place, the loader refuses to proceed. The lock would have to be a mechanism which the operating system removes no matter how the XMetaL process terminates (I believe a mutex satisfies this requirement). The flaw in this approach is that there is a small window of time between when the loader checks for the existence of the lock and when the XMetaL and the DLL are launched, during which a second instance of the loader could check the lock, find that it doesn't (yet) exist, and proceed to launch a second XMetaL process. This window would be so small that it seems safe to say that it could only happen if the user intentionally tried to launch two loaders as close to simultaneously as possible. This approach may be the best we can do, and I don't really think we need to worry too much about mischievous users trying to get around the lock. 😉

~oseipokuw is reviewing the described approach, and will confirm that he understands it and believes that it is worth the LOE to implement.

Yes, this is fine and you're right about no user would intentionally try to go around the lock. However, I would like to ask again to see if compared this approach you suggested, making it possible for users to safely log into multiple instances would be a better approach or at least compared to the current approach perhaps it wouldn't make it too expensive?

Hi ~bkline and ~oseipokuw - Let's discuss this more in a CDR meeting. This sounds like a very high LOE. Am I misunderstanding that?

I want to understand more about the use case and how common it would be, any risks involved for unintended impacts, and the overall benefits. Thanks!

It was decided in the status meeting to fix the bug, preventing users from running more than one XMetaL process at the same time (assuming it's possible to do so).

Implemented and installed on CDR DEV.

Verified on DEV. When on DEV, I am not able to log into another session of DEV (or PROD). However, I am able to log into another instance of (QA and/or STAGE), in addition to being logged into DEV. I assume that once the changes are copied to the upper tiers, it will prevent these logging into different tiers.

That's correct. As things stand right now, when you log into QA the loader installed on that tier is installed on your computer (we haven't yet promoted Ohm to QA). That loader doesn't know it's supposed to prevent you from running two simultaneous instances of XMetaL. So the software is behaving the way we would expect it to at this juncture.

Ok. Got it. Thanks!

I am running into a some issues when testing this out. While logged into QA, I am able to see the new TemporaryLink attribute on the DrugReference block. Then, when I try to log into PROD (while still logged into QA), I get several error messages that tell me that there is a mismatch and and as expected, I am not logged a second time into the CDR on a different tier. However, after this happens, I go back to look at a DIS to see if the TemporaryLink attribute is still available and I don't find the attribute in any new document I retrieve after that incident. It does look like when attempting to log into the CDR a second time, there is some type of refresh that causes the TemporaryLink changes to disappear. I think it would better to demo this to you. I will try and do that during the standup tomorrow.

Well, let's see how long Cynthia's agenda item takes. Remember, the standup is only 15 minutes. We may need to pick a different time for the demonstration of this issue.

We might not have anything to discuss. I have moved the check to make sure there isn't already another instance of XMetaL running earlier, avoiding the client file refresh (and therefore, I assume, the problems you reported above). Change installed on DEV and QA. Please test and verify that this eliminates those problems.

It looks resolved now. Thanks!

Verified on QA. Thanks!