Is ServerOperations.client thread safe or process safe

[fryhard]

Hi,

We are currently using the Vault API to provide a way of controlling our online content. Users within our local environment submit content to the websites by means of a client that communicates to a processing server with by means of a WCF service. This service places the content items onto a MSMQ. A Windows service then listens for messages on this Queue and commits them to Vault. From vault items are shadow copied to the hosting platform.

The problem we are faced with is that multiple processors running from the windows service interfere with the state of the VaultClientIntegrationLib.ServerOperations.client static variable. These processors are running in different threads.

Here is the basic flow of the queue item processors

• The processor of the first queue item will login to vault and start committing content
• The processor of the second queue item will login to vault and stat committing content
• The first queue will logout from vault
• This logout breaks the second queue item's operations since it logs the user out

We are now thinking of starting many instances of the processing application(separate processes) and processing the queue items this way. Before we make the code changes necessary to do this we would like to know if the VaultClientIntegrationLib.ServerOperations.client static variable is process boundary safe or not. (would one window process affect the state of another process' ServerOperations.client?)

Thanks for the help.
Regards
Brendan Fry

[jeremy_sg]

You're right. ServerOperations is not thread safe. It is process safe, but I can't promise you won't run into any bugs, depending on how hard you push it. We do lock all of our state files before reading or writing, so there shouldn't be a problem with simultaneous writes and reads.