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
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?