Tino Wildenhain wrote:
We do not talk about exceptions here. I'm talking about transactions.
And you never know who will be aborting a transaction after your
call to the function. No need for referral to the fine manuals :-)
Common Tino, you let users abort transactions? Who else is going to be
aborting transactions besides you the programmer?
I would never allow that as they would mess everything up.
I only abort transactions in my end user apps when the server throws a
error, I then evaluate that error and take appropriate action.
That's why having exceptions in your function would work. You are
inviting trouble letting users control when a transaction ends or starts
for that matter, they have a tendency to leave them in a non commited
state for long periods of time.
Transactions need to be short and sweet.
Sure a very long latency email might slow up a transaction for a second
or two, but like I said for a internal use corporate app, you will never
even see one second to send a email.
It all depends on your app what will work best.
There is nothing wrong with sending a email directly from a trigger or
function. If you really need to scale there are better ways, but for 99
percent of apps the way I suggested will work fine and dandy.
I myself, for a high volume email notifictation system would probably
use some form of a queue, but that would be severe overkill for the
majority of apps, if it's not broke don't fix it.
I guess we will have to agree to disagree :-)
Later,
Tony
