I have an Qaction A that receives changes from a table and triggers Qaction B. Qaction A writes to an invisible string "buffer" param that Qaction B reads from and deletes. The problem is that the table may have multiple changes. So as Qaction A is triggered multiple times it also triggers Qaction B multiple times. So depending on when Qaction B is scheduled to run the buffer may not be completely filled with the changes. Is there any way to tell how many times Qaction A is scheduled to run, and then run Qaction B when its finished? Can I see how many changes are in the table? Or is this just a bad pattern all together?
I believe the best way of doing something will heavily depend on what you are trying to achieve and the context of what can be triggered. Would be good to understand a bit more about what you are trying to achieve. Could you add more information on your use case and why you want to use a buffer?
You can add logging to your QAction to figure out how many times it is triggering during development and how long it takes. It is highly recommended to keep logging as low as possible to keep the load on your disk low, so best to disable the debug logs again after you are done with development.
Buffers are typically something we use to avoid your connector being locked for long periods because of the QAction that takes long to execute. If you can split up what you want to do into parts that take less time, then you can work with a buffer. To make the connector responsive again between the items of the buffer, we need to add a group to the stack that will process the next item so that other groups can also be executed in between. Below is a screenshot that might help you understand where on the stack a group is added (depending on the type of action used to put it on the stack).
Maybe by playing with execute next and execute, you might be able to reduce the number of times you trigger certain actions. Using methods with the keyword one will avoid putting the same group on the stack if it is already on there. More info on actions can be found here: Actions overview | DataMiner Docs
- Never save a buffer. Buffers change typically rather quickly and if saved it will on every change update the data in your DB, which will result in a lot of load on your DB layer. These issues can be difficult to solve later on (to find out why there is so much load on your DB).
- If you want to know what group your connector is currently executing you can use the protocol pending calls. To ensure your connector is responsive, you want to avoid it being stuck in the same group for longer periods.
- Try to reduce the protocol calls. If you are using protocol. (e.g. protocol.setparameter) methods, then try to reduce them (e.g. by using setparameters instead of the setparameter method) as much as possible as these will be the ones that typically generate the delays and/or generate the load on your system.
- If you are setting a parameter that triggers another QAction (without going through a group), then this will be immediate and no other actions can be done in between.