5 Replies Latest reply on May 2, 2017 8:32 AM by RLECORRE

    CheckOut problem

    RLECORRE

      Hi,

      We have a problem in a VB application using PIAF SDK when checking out an attribute.

      The attribute we are extracting is supposed to rename a file to give it a unique id. The attribute is checked out, incrementated by our application and checked in.

       

      The application is running by ACE contexts so we have multiple intances of the app and, sometimes, two instances are executing exactly at the same time (to the nearest millisecond). In this particular case, both instances are checking out the attribute returning no error. Therefore, two files are renamed with the same id.

       

      We have tried 3 methods from the AFCheckOutInfo class (IsCheckedOutThisSession, IsCheckedOutThisThread and IsCheckedOutToMe) to check if the attribute is already open but none of them returns a different response (same return values in both instances).

       

      Do you know if there is a solution to know if an attribute has been checked out and not yet checked in this particular situation?

       

      Thanks,

      Robin

       

      PS: it works normally when an instance check out an attribute before another one (temporizing until check in)

        • Re: CheckOut problem
          gregor

          Hello Robin,

           

          Please allow me to mention what you are doing appears a bit off scope what PI ACE is designed for. The check out mechanism in AF is to prevent against changes by another user while maintaining an object. Because I expect you have a single PI ACE Scheduler running those contexts in parallel, the check out will be done for the same user account which, as you already mentioned is not very helpful when processes are executed in parallel.

           

          Long story short, to prevent multiple threads to attempt accessing the same object at the same time, locking is useful. Are you operating with multiple files or is it a single one? If it is just one, you can obtain an exclusive lock to protect the file being maintained by another process. If you are dealing with multiple files, you may want to "abuse" another single file to prevent against concurrent access.

            • Re: CheckOut problem
              RLECORRE

              Thank you for your answer,

              Yes we are dealing with multiple files. This solution could definitly works but is there a way to do it with AFSDK methods? Shouldn't IsCheckedOutThisThread's method returns a different value?

                • Re: CheckOut problem
                  gregor

                  Hello Robin,

                   

                  IsCheckedOutToMe is not useful in your case because it will be the same account performing the checkout.

                   

                  IsCheckedOutThisSession and IsCheckedOutThisThread are returning a Boolean which indicates if the object has been checked out by the same Session or Thread. I wonder how you would like to use it? If the properties return true, well your code will likely not attempt twice to do a checkout on the object, does it? If it returns false, you still cannot assume the object has not been checked out. With other words, false could indicate the object is not checked out but also it is checked out but by another thread or through another session.

                   

                  The issue you are experiencing is a race condition and you need to find a way to reliably prevent running into this race condition. I assume part of the issue will be that contexts are scheduled naturally based on the same trigger or are clock scheduled with the exact same settings. One option to prevent the issue might be specifying a different calculation offset for each context.

                   

                  Have you tried to rely on AutoCheckOut (controlled through EnableAutoCheckOut property)? If your object is modified by another context, the next context might receive an error when attempting a modification.

              • Re: CheckOut problem
                Rick Davin

                One small clarification: you cannot check-out an AFAttribute.  Instead you check-out an AFElement.

                 

                As my colleague @Gregor_Beck  mentions the difficulty is that with ACE there can be parallel and concurrent requests which makes it difficult to get some sort of exclusive access to an element, not to mention introduces a race condition (example: the second request started finishes first).  But I am guessing the attribute you are trying to update is not being historized, i.e. is not a PI point.  If it were an attribute based on a PI point, there is no need to check out its parent element.  You could simply call AFData.UpdateValue to send an updated, timestamped value back to the underlying Data Archive.

                • Re: CheckOut problem
                  RLECORRE

                  Thanks for the answers, we'll try some of your solutions