A PDM race condition: How your code might wrestle with PDM when saving files directly to the vault — and what to do about it.

A race condition may occur when two instructions are executed at the same time. The output gets determined by which instruction finishs first. Usually, this produces inconsistent results and behaviors. The following instruction will always depend on having a consistent output from the previous one to execute correctly and that’s what makes a race condition hard to fix. There is quite a bit of concurrency to deal with.

There are some interesting race conditions that can occur between SOLIDWORKS and PDM Professional. I’m going to explain one in this article.

Assume you have a giant file (+100 MB) you’re saving to PDM. Conventional wisdom says that you save the file directly to the vault and you use IEdmFolder5::AddFile to add the file.

This is wonderful and it works well if the file’s extension is not part of the Adding Files option below.

The PDM client is constantly watching for files with those extensions to appear in the local cache so it can add them to the vault.

This feature is argubly a good and a bad one at the same time.

From the user’s perspective, it saves them time having to right-click on files and click Add To Vault. It works well for sld extensions (sldprt, sldasm and slddrw).

From the API perspective, however, it creates a race condition with IEdmFolder5::AddFile if this API call is used right after the file is created in the local cache (by IModelDoc2::Save for example).

If PDM auto-adds the file first, IEdmFolder5::AddFile will re-add the file to the vault causing unnecessary copying. The final output of that race condition would look something like this:

Any good solutions, eh?

There are a couple of solutions to remedy this issue. We’re going to list a couple of them below.

• We can stop using IEdmFolder5:AddFile in favour of PDM adding the file on its own. We still need to get the IEdmFile5 object so we can check the file in (for example). Using IEdmVault5::GetFileFromPath is likely to fail because of the race condition. Instead, we can IEdmVault5::TryGetFileFromPath which has a timeout. We can set the timeout to 30 seconds which more than enough for the file to be added.
  
  IEdmVault5::TryGetFileFromPath is an extension method from BlueByte.SOLIDWORKS.PDMProfessional.Extensions a nuget package of useful code for PDM. Unfortunately, this solution does not work if the file takes longer than 30 seconds to be added by PDM.
• The other approach is to temporarily disable the auto-add feature in PDM. Unfortunately, there is no API call to perform this and frrom my interactions with API support, it doesn’t look like this option will be added.
  

• The best solution is to save the file to a temporary location (C:\Temp for example) and then use IEdmFolder5::AddFile5 to add the file back into PDM.
  
  

Can I reproduce this issue?

You can replicate it with this example on our GitHub.

What’s next?

This article explores one of many race condition examples between PDM API and SOLIDWORKS API and there are more. If you are struggling with one, sometimes bringing experts to make your PDM workflow more efficient can save you valuable time and internal resources.