Question
Regarding database commit in Declare Triggers
The following line is from Pega 7 Help:
"An activity of type Trigger may alter properties, call functions and execute other rules, but do not perform database commits. "
In the following PDN post (https://pdn.pega.com/community/product-support/question/declare-trigger…) , a person has mentioned that s/he is using a Declare trigger activity to Queue a Work Object to an agent. This would involve creation of a record in pr_sys_queues table. How is this possible if we consider the line from Pega 7 Help. Can somebody help me understand the meaning of "but do not perform database commits"?
***Updated by Moderator: Marissa to update categories***
Hello Tuhinguha,
The trigger activity can put things like the queue item save onto the deffered list, for another process to commit. For a deffered save/delete trigger, that would be fine because there will be a later coomit to get everything down to the DB. In the case of a trigger fired on commit, I believe it will fire before the commit action is done on the database. So in essense, I believe the other poster you linked to is working off of a flawed assumption. I looked through the help and it isn't entirely clear, and it's been a while since I've played with this so my memory could be wrong. You could certainly test this fairly easily by adding a counter to an object and then creating a commit trigger that will add one to it. After the commit, you open the item, has the counter gone up by one or two?
Thanks,
Mike
Well, I know one important thing is to avoid unintended recursion. So if your trigger is on commited saves to class X, you wouldn't want to write anything to class X within that trigger, lest the same trigger try to fire within the one already firing.
However, if your trigger is writing something to a second class, that should be ok.
But the "commit" activity method step is a general write-all-deferred-records-to-ALL-classes directive, so that could cause trouble.
To avoid that "commit" from your trigger, you could do an obj-save with "write now" for your pr_sys_queue table entry, and as long as you don't have a trigger on writes for THAT table, you should be ok. /Eric