2 Replies Latest reply on Sep 1, 2012 12:31 PM by hamrichards

    Are IWP scripts multi-threaded?

    hamrichards

      I'm revising a single-user FMP boat-reservation database to enable it to be accessed remotely via IWP. Now for the first time this database will be accessible by multiple users.

       

      One operation of this database displays a set of records of a table, RD, representing available time slots for a given boat on a given date. After updating the records for the desired slots, the user clicks a button to commit the changes and close the time-slot display.

       

      In the new multi-user IWP environment, several users may be working on subsets of table RD’s records simultaneously. As long as the subsets are disjoint, i.e., they represent different boats or different dates, there's no problem, but overlapping subsets must be prevented--we want each user's access to time-slot records for a given (boat,date) to be exclusive. A user requesting to display times for a (boat,date) on which another user is working will be notified that the (boat,date) he's requesting is temporarily busy.

       

      Because each user works on batches of a couple of dozen records, FMP's record locking provisions, which work only for individual records, don't solve this problem. What's needed is for each record to have an in-use indicator, set when it is made active, tested before it is made active, and cleared when it becomes inactive. All of this testing and setting is of course performed by scripts.

       

      If users were able to access this database using several clients, this solution would obviously fail. Two clients could check a record's in-use indicator in quick succession, both concluding that the record was inactive and proceeding accordingly. FMP's record locking would prevent two users from reserving the same time slot, but the timing could work out so that they got alternating slots.

       

      With IWP, however, it's my understanding that there's only a single client serving all IWP users of a given database. In that case, the test-and-set solution works if scripts are single-threaded, i.e., if a script runs to completion for one IWP user before it begins execution for another user.

       

      Is that the case?

       

      Thanks for either an answer or a link to the answer.

       

       

      ---Ham

        • 1. Re: Are IWP scripts multi-threaded?
          Mike_Mitchell

          In a case like this, I would suggest revising the interface to take advantage of record lock ... just not in the way you're thinking.

           

          Change the interface in a way so you have a master record and a portal that reveals the associated records that the user in question should have access to at the time. Each user could have a record, if you like, or you could do it on a session basis, depending on workflow. When a user went to perform this particular operation, you can have a script open the master record AND open the portal records. This will cause FileMaker to lock the master record and the related records as well.

           

          If another user wants to use the records, he'll get a record lock collision, which you can manage in scripting.

           

          When complete, a simple Commit Records will return the records to the other users.

           

          HTH

           

          Mike

          1 of 1 people found this helpful
          • 2. Re: Are IWP scripts multi-threaded?
            hamrichards

            Thanks, Mike. The approach you suggest looks promising. In my 20+ years with FileMaker I haven't had much occasion to use portals, so I've got some reading to do (in R. Cologon, FileMaker Pro 10 Bible). I'm looking forward to putting the idea into practice.

             

            It occurs to me that another advantage of the portals approach is that it doesn't depend on scripts being single-threaded. That will be important when my project extends to include FM Go.

             

            All the best,

             

            --Ham