Re: ESQL/C transaction

>From: Bharat Shah <uunet!unifi!goofy.unifi.com!bharat> >To: coburn@informix.com >Subject: Re: ESQL/C transaction >Date: Tue, 27 Apr 93 9:05:27 EDT >X-Informix-List-Id: <list.2205> > >Your suggestion about restructuring code is good one !! >But in my case every function which begins work ... does commit/rollback >work ! >Its the other library-calls which cause a problem. >Anyways, >The latest thought is to protect each 'begin' with check for 535 >and each rollback/commit with check for 255. > >This will solve the problem ... but will I be sacrificing any built in >safety-net ?? Yes, and no. Suppose FunctionA calls FunctionB. If FunctionB unconditionally starts a transaction and commits it, and FunctionA does the same but calls FunctionB part way through, then whatever transaction FunctionA is trying to handle gets committed by the commit in FunctionB -- which is disastrous as far as FunctionA is concerned. You have to revise the semantics of FunctionB so that if it tries to start a transaction and succeeds, then it also commits. If, on the other hand, it fails to start a transaction, it must not commit it. If it needs to rollback the transaction, then you have to have agreement amongst your library functions on how you will handle it. Presumably, FunctionB would report the error via the return status, and FunctionA would abandon (or restart) its transaction. I don't think anything less will solve the problem. I also think that the use of functions to handle the commit/rollback etc will be necessary because if you have the same code littered all over your library in longhand, you will live to regret it bitterly on the day when the semantics of commit/rollback etc change. Yours, Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h>