How should I be calling database queries (INSERT) from tag changes events?

Ignition
1

I know tag change event scripts shouldn't run for longer than a handful of ms, so direct database queries are out of the question. But what other methods should I use to call database queries, specifically INSERT statements, from a tag change event handler?
Using system.util.sendRequestAsync?

I'd prefer to use tag change events rather that gateway tag change events since I have a lot of UDT instances that include tags that will use this. They won't be running this very often, but for argument's sake, assume that it will. The tag change events essentially logs a record into a table.

Related question: is system.db.runSFPrepUpdate included in the 'no-go' functions for tag change events?

2

I use this all over the show by calling system.util.invokeAsynchronous from tag change scripts. I know it is expensive to call, but it frees up the tag thread pool.

All tag change scripts either execute near instantly, or invoke async. The gateway runs about 430k tags and going strong.

3

I would expect it to be fine. (And much less overhead than system.util.invokeAsynchronous.) That's essentially what tag history does. You can use System.nanoTime() to confirm.

1 Like
4

I wonder if it's worth creating/exposing a worker pool specifically for scripting for this kind of stuff, to minimize thread creation hits by recycling as much as possible. Probably a dedicated facility, so it's easier to troubleshoot if someone mishandles it, but then everyone who gets into advanced patterns doesn't have to worry about creating and managing their own executor...

4 Likes
5

That's a good idea. Perhaps a gateway-scope version of system.util.invokeLater() Something like system.util.invokeInPool() with configurable thread pool size? (Then I could drop the faker I put in later.py.) The delay option cuts out a lot of excuses for using .sleep(), too.

Hmmm. I really like this idea, particularly if it coalesces like EDTUtils. I'll add this to Simulation Aids with a conditional load (so it'll gracefully disappear when implemented first-party). I think the default thread pool should be generous--5x CPU cores or so, so that SQL query duration isn't a big deal.

{ I realized this facility would be super-useful in Vision, too, and definitely needs to be understood as not running on the EDT. }

3 Likes
6

Yeah, I suppose just exposing a Scheduled executor service would kinda trample on gateway timer scripts. So some kind of nicer facility would be good.