# When are transaction groups the best solution? **URL:** \ **Category:** Ignition\ **Created:** [April 11, 2025, 11:48pm UTC](https://forum.inductiveautomation.com/t/when-are-transaction-groups-the-best-solution/105025 "2025-04-11T23:48:52Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Simon\_Hathout\_Willar](https://avatars.discourse-cdn.com/v4/letter/s/3da27b/32.png) [@Simon\_Hathout\_Willar](https://forum.inductiveautomation.com/u/Simon_Hathout_Willar)\ **Post date:** [April 11, 2025, 11:48pm UTC](https://forum.inductiveautomation.com/t/when-are-transaction-groups-the-best-solution/105025/1 "2025-04-11T23:48:52Z")
I'm working on (re)writing some code, which logs CNC machine statuses. There's some logic with translating from the machine's statuses to a shared set, and HMI overrides to the status, but nothing too complex. The previous solution was using gateway event scripts on the machine status tags, doing the translations in scripting, writing them to tags, and then using transactions groups on these tags to store them. Considering that all the transaction groups are doing is waiting for the script to finish, and then writing the data to the database, a simple named query at the end of the script is likely a more elegant solution in this case. Are transactions groups mostly meant for the mid-complexity use cases, which are more than the Historian is built for, but not enough to warrent writing a whole script? For example storing a value whenever a second "latch" value comes on? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 12, 2025, 12:03am UTC](https://forum.inductiveautomation.com/t/when-are-transaction-groups-the-best-solution/105025/2 "2025-04-12T00:03:57Z")
IMNSHO, Transaction groups are for drag-n-drop designer activities for people you cannot trust to write a proper script. 🤷‍♂️ ---
**Author:** ![Simon\_Hathout\_Willar](https://avatars.discourse-cdn.com/v4/letter/s/3da27b/32.png) [@Simon\_Hathout\_Willar](https://forum.inductiveautomation.com/u/Simon_Hathout_Willar)\ **Post date:** [April 12, 2025, 12:08am UTC](https://forum.inductiveautomation.com/t/when-are-transaction-groups-the-best-solution/105025/3 "2025-04-12T00:08:34Z")
Are there that many people working on your ignition system without scripting knowledge, that it's a useful tool to have? My initial guess was that transaction groups would be a lot faster than scripts (because they're only using expressions). But, I can't find a way to have them run off UDTs, which are the only way I can see having enough objects to justify the performance (unless you write 500 transaction groups manually?) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 12, 2025, 12:12am UTC](https://forum.inductiveautomation.com/t/when-are-transaction-groups-the-best-solution/105025/4 "2025-04-12T00:12:46Z")
Perhaps you are ready for the rabbit hole. Start here: > [@\[SOLVED\] Are tag Value Changed scripts running asynchronously?](https://forum.inductiveautomation.com/t/solved-are-tag-value-changed-scripts-running-asynchronously/68704/5): > > 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. Then this: > [@Java concurrent queue for tag change scripts](https://forum.inductiveautomation.com/t/java-concurrent-queue-for-tag-change-scripts/82044): > > Continuing the discussion from [[SOLVED] Are tag Value Changed scripts running asynchronously?](https://forum.inductiveautomation.com/t/solved-are-tag-value-changed-scripts-running-asynchronously/68704/5): We've got code in our standard library that I need to log a value change on a tag and then associate various data points with that value change. The value is located in a UDT, and because this is part of our "standard" library we use for our customers, the number of tags is variable and quite possibly numerous so having a gateway tag event script isn't feasible for this solution. I was reading up on … And this: > [@Modbus Slave/Server to Generate Read Only Tags](https://forum.inductiveautomation.com/t/modbus-slave-server-to-generate-read-only-tags/87583/21): > > I've create a generic "Modbus Publish" script that eliminates the need for a second set of tags. I've publicly posted it here: [https://www.automation-pros.com/ignition/modbusPublish.py](https://www.automation-pros.com/ignition/modbusPublish.py) It requires the "Queue Utility" script posted here: [https://www.automation-pros.com/ignition/queueUtil.py](https://www.automation-pros.com/ignition/queueUtil.py) and described over here: Both scripts rely on my Integration Toolkit's globalVarMap() script function, but you can rework that (not quite 1:1) to use system.util.getGlobals() if you must. (Not recomme… And finally this: > [@Automation Professionals' Integration Toolkit Module](https://forum.inductiveautomation.com/t/automation-professionals-integration-toolkit-module/74934/212): > > Meanwhile.... Automation Professionals is pleased to announce a BETA release of this module, with a significant new feature: Tag Actors. For Ignition v8.1+: v2.1.0.250841756 The details of the new functionality are in the freshly updated documentation, under [Tag Actors](https://www.automation-pros.com/toolkit/doc/actors.html). The Republish action provides a built-in alternative to the Modbus Publishing algorithm I recommend over here: The Republish action can also be used with expression tags to revive the old OPC writeback functionality, witho… ---
**Author:** ![Simon\_Hathout\_Willar](https://avatars.discourse-cdn.com/v4/letter/s/3da27b/32.png) [@Simon\_Hathout\_Willar](https://forum.inductiveautomation.com/u/Simon_Hathout_Willar)\ **Post date:** [April 12, 2025, 12:20am UTC](https://forum.inductiveautomation.com/t/when-are-transaction-groups-the-best-solution/105025/5 "2025-04-12T00:20:43Z")
Java thread pools and race conditions.... I though I had escaped those. Anyways, looks like some very useful reading that I'll delve into later. I keep meaning to download the toolkit module (as well as some better charts for perspective), but unfortunately my boss is a bit wary to include 3rd party modules.