5 Sep
2006
5 Sep
'06
5:16 p.m.
Ron Winacott wrote:
On Monday 04 September 2006 10:26, Bogdan-Andrei Iancu
wrote:
actually the "may" was for the script writer - he can explicitly destroy
the transaction via t_release() or indirectly via t_reply() / t_relay().
If he does not handle properly the transaction in the script, the TM
module will take care of it and destroy the transaction but it will
generate some logs about it...
You can test this by doing only a "t_newtran()" for a request without
forwarding or replying it....:)
regards,
bogdan
Based on this, here is what I suggest:
1) have a new param for disabling the auto reply in t_relay()
2) t_relay will return several error codes:
-1 = no transaction created -> need to use sl_* functions
-2 = transaction created, relay failed -> may destroy
transaction, reply via TM with error, trigger failover.
any comments on this ?
This all sounds good for the following reasons:
1) - The new parameter covers the backward compatibility case where the
script wants the old way of doing things.
2) - I assume there will be new script calls to deal with deleting the
failed transaction, and the transaction could be freed once the script exits
to avoid memory leaks. If not freed by the script call.
My only concern is, do you think the two result/error codes are sufficient to
cover all of the cases? The idea of "may destroy" leaves me with an uneasy
feeling.