Re: ESQL/C transaction

>>>>> On 26 Apr 93 23:18:05 GMT, coburn@informix.com (David Coburn) said: > In article <1rgqc7INN72m@emory.mathcs.emory.edu> unifi!goofy.unifi.com!bharat@uunet.UU.NET (Bharat Shah) writes: >>I have multiple libraries of ESQL-C functions. A lot of them call one >>another. Some functions also have begin/rollback/commit transactions. >>Problem I face is before starting transaction, how can I detect that >>a transaction has already been started ?? >>Multiple "begin work"s obviously (and correctly) is unsuccessful and >>returns error. >> [...] > At a deeper level, though, you may want to spend some time thinking about > the structure of your code. I have found that when I want to end a > transaction in a function other than the one that began it, the code is > invariably poorly structured to begin with. This normally means that some > rethinking is in order, with an eye to simplifying and modularizing the > code. I'm not trying to criticize your code or anything, as I've been in > your situation more times than I care to remember. But, like I said, I > have never seen a situation where the real problem was other than poorly > structured code. By the way, this applies to every language I've used, not > just ESQL/C. I do not agree at all. We use transactions to achieve row level locking during user interaction. Every object which is displayed on screen and may be modified by the user remains locked until the user either releases the object or stores her modifications. Any object may reference other objects. Referenced objects may also be displayed and modified via popup windows (think of some kind of zoom function). These objects again use transactions for row level locking. The locking routines do not know about any transactions which may have been started before. So we use a nested transaction strategy. We never call 'begin work' or 'commit work' directly. 'rollback work' is never called except for error recovery. Two functions called ta_begin_work() and ta_commit_work() maintain a counter called the transaction level. So just the outermost transaction is a 'real' one. Everything else just increments/decrements the counter. If I remember correctly even C. J. Date mentions the notion of nested transactions. I assume there has been quite an amount of research on this topic (partial commits, isolation and so on). I doubt all this can be judged as a result of 'poorly structured code'. -- Oliver Okrongli infix Software-Systeme GmbH Phone +49 531 238090 Rebenring 33 Fax +49 531 3801152 oliver@infix.de D-W-3300 Braunschweig F.R. Germany