Server-side scripting

[LaRetta]

I'm unsure whether to post in ScriptMaker or here ...

We are firing scripts from FM Server and two scripts have been fired at once within FileMaker. I know this because of the overlap of resulting records which were created (I can show everyone if they wish to see the proof of such an overlap).

My question is ... shouldn't FM Server finish one script before starting another? Each of the two scripts in question fire their own sub-scripts. But it is my understanding that one script (including all of its sub-scripts) should finish before the next script can even start. But that is not what is happening. And the two scripts firing together is causing problems for us (one script fires every 5 minutes and other other fires every hour).

For now, we have staggered the times a bit but it still concerns me. I know that FM will not allow another script to fire until the first one is finished ... but that is a client. What about the Server situation? I feel like I'm working blind with server-fired scripting.

LaRetta

[Steven H. Blackwell]

I know that FM will not allow another script to fire until the first one is finished ...

Not necessarily. I agree that the situation you report is unusua.

Maybe try an error test at the beginning of each script to see if the other is running?

Steven

[IdealData]

I'm sure you'll understand this one...

If $$script_running = ""

Set Variable $$script_running; "yes"

.

run rest of script

.

Set Variable $$script_running; ""

End If

[Kris M]

If you do this...

If $$script_running = ""

Set Variable $$script_running; "yes"

.

run rest of script

.

Set Variable $$script_running; ""

End If

and something unusual happens to the application that causes termination after the set variable $$script_running = "Yes" assignment but before the set variable $$script_running = NULL assignment then you will not be able to run the script again until you figure out how to renull the variable.

Correct?

[LaRetta]

Sounds good in theory. But I am greatly concerned and I think we should be. I don't believe I'm the only one who would expect server-side scripts to maintain the one-at-a-time sequence. There are too many questions I have to address here but, taking your example even ...

If you use one global variable quite often in your scripts (same name) then you will depend upon that value being dependant upon the point of view of THAT script and THAT perspective when THAT script fires based on THAT layout and table occurrence. What will happen when two scripts fire who use the save global variable? Their values would/should be different. Are they different if the scripts run simultaneously?

FileMaker really has not provided us with a clear picture of server-side script functionality. It feels like *we* are the experiments here. My perspective in scripting is from client perspective as is expected ... that is all I have known. I keep thinking, 'when is a client not a client' and it feels like a riddle and it is. I have trouble getting my head around all the inconsistencies in perspective. How are globals viewed/handled? If it is a client in the global field perspective, why is it not a client in the no two-scripts-at-once perspective?

Far too many questions and no answers in sight.

[mr_vodka]

I agree that we could have more thorough documentation about the ins and outs. I believe that what happens with Server side scripting is that FMS creates an IWP-like instance session on the server to process the scripts. My guestimate.

[Steven H. Blackwell]

All these server side connections are listed in the logs.

Next week, VTC will release a series of videos on Server 9. There are several about the logs and a specific instance of a server side script connection.

Steven

[IdealData]

How about pausing the script for a specified time at the very beginning.

[LaRetta]

Hi Mark,

Yes, we are now staggering our scripts' start times. But with many of them running (and some running at 5-minute intervals), some at an hour and so on, there is still possibility of overlaps. I would really like to understand ... how would a pause in the script make a difference?

I also keep up on Real Tech and Tech Talk and AFAIK nothing has been discussed on this issue yet. I just hope that, as people begin using server-side scripts, that they share what they learn about FMS' pseudo-client status and I hope these subtle differences are discussed at DevCon this year. Thank you for responding!

UPDATE: Oh, and I also considered using Get ( ScriptName ) and testing whether another one was running. But since two scripts can fire simultaneously, the test still wouldn't protect unless it tested between every script step. Besides, it seems that this would be a Get() function which would be evaluated client side and not server side. When I search Help, I find in Solving calculations on a host machine, Get() functions and where they are evaluated. But of course Get ( ScriptName ) is not included. It would be nice, if FM is going to provide this list, that they include ALL Get() functions.

LaRetta :wink2:

Edited July 5, 2008 by Guest
Added Update

[Christine Sephton]

I have actually ran into the same issue, with script overlapping however we found that each script created its own IWP session. Since no documentation has been released, and this is a guess, we have a preference files, where we store our standard application information. Within this file we have a field called "Server Script Status". When a script runs, it calls a subscript that checks to ensure that field is marked as "Idle". In the event it is not, we do a loop, allowing it to only exit if the field becomes "Idle" After it is released from the loop, the script will successfully execute.

*To save server resources, you can place a 1-5 minute pause before it checks the field value again.

Christine

[LaRetta]

Thank you so much, Christine!

And maybe this is the pause that Mark mentions and we will incorporate these additional protections. So I would guess that every server-side script will need to write to Prefererences when it has been passed the baton so only one script can fire at a time (if they touch the same table occurrences at least).

It is possible that some scripts can fire simultaneously and be safe but I would not trust such a theory, envisioning hitting the same record or field at same time! It makes me shudder. It seems more important than ever to also chain scripts so they run each sub-script in their entirety so they don't trip over their own feet (overlap sequences). Maybe those who work with IWP already deal with possible script overlap but I will have to change my thinking in this regard.

LaRetta :wink2:

[fabriceN]

Hi!,

I think this is perfectly sandard behaviour for server-side scripts, since web users would have to wait a long time for each request they make if scripts were queued.

The problem is about transactions: what you would expect is that all created/modified/deleted records by a script would be committed at the end of the script, and all at the same time.

But this is not the way FileMaker works. By the way, this is not specific to server side scripts: if two users import data at the same time with a FileMaker client, records will be mixed in the creation order.

This is where our audit log system is nice, because it makes it all transactional, but it doesn't apply for IWP, unless you script navigation (which I would recommand to do anyway)

So I would compare your situation to any classic situation where you have a temporary table where you do import/export.

To make it multi-user (here multi-script), you must mark all records with meta data: script name, parameter, user information (IP...), then you're able to identify what caused what, and to perform find before doing post-treatments.

HTH,

Fabrice

Edited July 6, 2008 by Guest

[Doktor Joy]

Just to add to this, and more as an FYI than anything else:

I have found that if two scripts using the SmartPill plug-in overlap when executing server-side, one of them goes into an infinite loop, CPU usage hits 99%, and the server performance (understandably) goes downhill.

Unchecked, the server will eventually crash due to memory shortage (takes a couple of days usually).

I am currently getting round this with staggered script execution times, while I try to investigate whether this is down to my bad script programming, or the way FMS implements server-side scripts and their use of plug-ins.