Nested/Multiple transactions with SE

Path: emory!swrinde!sdd.hp.com!cs.utexas.edu!uunet!psinntp!uupsi!gdc!nms!bergquis From: bergquis@nms.gdc.com (Brett Bergquist) Newsgroups: comp.databases.informix Message-ID: <411@wimpy.nms.gdc.com> Date: 31 Oct 91 13:45:06 GMT Organization: General DataComm, Middlebury CT My environment is: Informix SE Informix ESQL/C SunOS Database with transactions I have a GUI application that allows the user to view and create multiple entities at the same time. I would like the user to be able to also modify these entities simultaneously. Each entity being modified or created is unrelated to any other entity being modified or created. Main Window +------------------+ | <load> <create> | | | | +--------------+ | | | |<---- List of entities | | | | | +--------------+ | +------------------+ Entity/Modify Entity/Modify Entity/Create +------------+ +------------+ +------------+ | | | | | | | | | | | | | | | | | | | | | | | | +------------+ +------------+ +------------+ The problem that I am having is that Informix SE does not allow multiple independent transactions to occur at the same time, nor does it allow nested transactions. To get around the nested transaction problem, I've written a set of functions that mantain a transaction nesting level indicator and only begin a transaction if the level is 0, only commit the transaction if the level is 0, and rollback the transaction the first time the rollback function is called. All other calls to my functions merely increment or decrement the transaction level. My first attempt for the above application had a being started for the first entity to be modified, and nested transactions for each additional entity to be modified. The problem occurs when modifications are made to one entity, and committed, but modifications to the second entity fail and the transaction is rolled back. Using my nested transaction functions, the first commit merely decrements the nesting level. The rollback however, performs a real rollback, causing the modifications to the first entity to be rollback as well. The same problem occurs if an entity is created and committed after another entity is created for modification and this entity rolls back its modifications. The created and commit entity is also rolled back, making it cease to exist. My second solution requires that only one transaction may be occuring at one time throughout the application process, thus only one entity may be in a modification or creation state at a time. This leads to a reduced level of functionality for my application. What is really needed is a way to have multiple independent transactions. Another possibility that occurred is to fork a child process for each modification/creation window and open the database in each child process. This is complicated and resource inefficient. Not only will there be a separate process for each child, but also a database backend process for each child. With terminal based applications, this scenario probably does not occur often, but with the popularity of GUI based applications, this seems to be a problem that will often occur. Any comments/suggestions. -- Brett M. Bergquist, Principal Engineer | "Remind me" ... "to write an General DataComm, Inc., | "article on the compulsive reading Middlebury, CT 06762 | of news." - Stranger in a Strange Land Email: bergquis@nms.gdc.com