Question
Infosys
IN
Last activity: 11 Nov 2016 2:09 EST
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://collaborate.pega.com/question/declare-trigger-committed-save-firing-commit) , 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***
Accepted Solution
Pegasystems Inc.
US
Pegasystems
US
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
Accepted Solution
Pegasystems Inc.
US
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
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