[Bug] Writing to the same trace in Citadel from two Sources at the same time

Question

Howdy
I am experiencing an issue and am looking to get some NI support:
I have two distributed applications that can write to a Citadel database at the same time.
And I am investigating the possibility of what would occur if both of them were writing to the same variable at the same time, with possibly the same timestamp data.
I did this in the attached VI by using the same timestamps with a constant for the data (either #1 or #2).
This generates an error, as expected, stating you cannot have two references open at the same time.
The data file, dumped from Citadel, contains 1000pts with all data from only one of the arrays (in this case #2) and everything looks fine:
However, what appears to be happening randomly tho, is that the same portion of code can also returns no error.
When the data is dumped from Citadel this file contains 2001pts - 1000pts from each array and one separator (or break) point:
You cannot write an older timestamp to Citadel without it throwing an error, but from further testing it seems you can write the same timestamp repeatably. So I am guessing what is happening above is race condition that is somehow allowing two references to be opened to Citadel which should throw an error but it does not and this is somehow allowing both sets of data to be written by both loops??
The data, IMO, is now corrupted.
Is being able to write to the same timestamp a desirable feature?
Or is this a known issue or a bug?
What about acquiring two references - bug?
Is there a workaround to protect the data from multiple distributed-application writes?
Cheers
-JG
Attached VI was coded and tested using LabVIEW 2009 SP1, DSC 9.0.1, MAX 4.6.2f1
Certified LabVIEW Architect * LabVIEW Champion
Attachments:
dual_databaseWrite.vi ‏21 KB

Answer 1

Ben S wrote:
The race condition of opening the refererence in two places at once should still apply to two different VIs running at the sametime.
Will a CAR be lodged for this?
Ben S wrote:
If you open up the code and save it as a .vit, you don't get any missing VIs. Only when you change the extension without the aid of LabVIEW.
No VI should have missing members by simply renaming its extension outside of LabVIEW???
I think there is an issue with the VI.
Can you replicate the following and verify what I am seeing?
Attached is a Project with Main VI (contains a call to the Open Trace.vi polymorphic only), a Class and a Build Spec
If you Build the spec with the Main VI outside of the Class it works
If you place the VI in the Class, save then Build, the Spec fails with the error:
Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1003 occurred at AB_Application.lvclasspen_Top_Level_VIs.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW:  The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.
Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1003 occurred at AB_Application.lvclass:Open_Top_Level_VIs.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.
Next place a disabled structure around the Polymorphic VI (as Class Member or not, it doesn't matter)
Save the VI
Close the VI
Open the VI - the Open Trace.vi polymorphic is "missing"
Cheers
-JG
Code in LV2009
Certified LabVIEW Architect * LabVIEW Champion
Attachments:
DSC.zip ‏341 KB