Let's say I have 10,000 tags with a tag Value changed script on them that modifies a single dataset tag when a change occurs. (Maybe add a row to the dataset or delete a row).
To modify the dataset I have to have the tag value changed script read the dataset, make modifications, and then write the new dataset (erasing the original dataset).
It is possible 2 tag value changed scripts will be called at the same time. Will the script read their own copy of the dataset or will script 1 complete before script 2 begins?
I am not worried about speed as much as I am about data integrity here.
By default, three tag event scripts can run in parallel in the thread pool. So data integrity would be a problem. Consider using an single gateway tag change event that is subscribed to all relevant tags. That will singulate as you desire.
5 Likes
Not that I'm gonna rush out to do it but you mentioned "by default". Is it possible to limit Ignition to a single thread?
There's a startup parameter intended to increase the number of threads for large systems. It is the same thread that does expression and query tags, IIRC. I would consider it a bad idea to reduce it.
Read-modify-write is simply a bad pattern. If the scripting will be the source of truth, consider only doing the read on script startup and caching the dataset in the script module the rest of the time.
If it absolutely has to be a tag event, consider calling into a script module that will submit the event to a java concurrent queue, then run a timer event with a dedicated thread to drain the queue and loop through the queued events.
1 Like
The end goal is having a table and a few buttons on a perspective page. Some field devices then activate the tags which update their values in the dataset tag (add, delete, or modify row).
Essentially re-creating a database table.
The reason for this is the Ignition server and database will be in the cloud and there will be a real cost for each call to the database.
The simplest solution is to use the single gateway tag change event. I would use the caching approach to make it fast. You could even avoid the initial read because any scripting restart will fire the event for all tags with the initialChange flag set.
2 Likes