Issue 51: Object Caching Problem (transactions) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: When a single transaction includes both recoverable objects and procedural database systems, a caching problem between private and system copies of the data can arise. Resolution: Revised Text: Updated by adding the Synchronization interface and its 2 operations Actions taken: July 10, 1996: received issue January 6, 1997: closed issue Discussion: End of Annotations:===== From geoff Thu Jul 11 15:42:59 1996 Received: by amethyst.omg.org (5.4R2.01/1.34) id AA20781; Thu, 11 Jul 1996 15:42:59 -0400 Date: Thu, 11 Jul 1996 15:42:59 -0400 From: geoff (Geoffrey Speare) Message-Id: <9607111942.AA20781@amethyst.omg.org> To: issue-logger@omg.org Subject: OTS Revision - The Object Caching Problem X-Omg-Issue: 51 Return-Path: To: transactions-wg From: "Edward Cobb" Date: 10 Jul 96 15:08:24 Subject: OTS Revision - The Object Caching Problem Mime-Version: 1.0 In our implementation of the OTS, we uncovered a problem when a single transaction includes both recoverable objects and (procedural) database systems when object data must be made persistent in an underlying database at commit time and an object is keeping its own (private) copy of that data. In order for the database to properly reflect all state changes, the object must flush its data back to the database system BEFORE the database manager is told to prepare. If the transaction manager tells the DB system to prepare first, the object will get an error when it tries to empty its state back to the database (the X/Open specification disallows new data to be added to a transaction after the transaction is prepared). Since there is no provision for ordering the Resource objects and resource managers to be called at commit (and one can easily construct other failure scenarios if one tries to solve the problem by ordering), this problem needs an alternative solution. In fact, there is a solution with the specification as written, but it is expensive in terms to complexity and footprint and seems to us to be much more complicated than necessary to get the object to flush its state back to the database. Incidentally this is actually what happens with an OODB, but when a RDB is used, there are multiple levels of buffering going on and (potentially) multiple levels of recovery. The solution that does work with the current specification is a follows: 1. An object (B) desires to maintain a cache of data which is derived from a RDB and then stored back at commit time must register with the OTS (A) to participate in two-phase commit as a subordinate coordinator. 2. The database system (C) xa_registers with this recoverable object (B) rather than the common procedural transaction manager (A). 3. Thus the transaction tree looks like A-->B-->C rather than A-->BC or A-->CB which actually produces the problem. Since only B is known to A, C will never receive prepare from A, but only from B acting as a subcoordinator which enables B to flush its data to C prior to sending prepare. This works (trust me), but requires B to engage in recovery logging (it must persistently remember A and C) and participate in transaction restart. This seems a high price to pay for simple caching, especially when you configure both A and B to be in a simple client machine and C to be on a more robust, secure server, which can handle that sort of thing. Most of the complex recovery code would now need to be on the client as well as the server. An alternative solution that we have come up with (detailed change pages to be provided) involves the introduction of a pre-prepare phase (and it turns out a post-completion phase as well) into the two-phase commit process. The solution is optimized for an implementation that does interposition, which makes the new calls local to a single domain rather than additional passes down the networked commit tree. The solution has the following elements: 1. A new form of registration which activates pre-prepare and post-complete processing, using a new synchronization object, rather than the Resource object. This permits caching implementations that do not need to participate in two-phase commit processing to sign up for buffer flushing without incurring all the burdens of full two-phase commit processing (logging, commitment, restart). 2. A change to the behavior of a Coordinator which requires the polling of the synchronization objects with pre-prepare before starting the two-phase commit and polling with post-complete after all yes votes have been collected. 3. A change to the behavior of an inferior coordinator to require him to behave as in item 2 when he receives a prepare from his superior coordinator. I'd appreciate feedback on the problem from other implementors as well as their thoughts on my (or other) possible solutions. Ed Cobb From geoff Thu Jul 11 15:43:42 1996 Received: by amethyst.omg.org (5.4R2.01/1.34) id AA20810; Thu, 11 Jul 1996 15:43:42 -0400 Date: Thu, 11 Jul 1996 15:43:42 -0400 From: geoff (Geoffrey Speare) Message-Id: <9607111943.AA20810@amethyst.omg.org> To: issue-logger@omg.org Subject: OTS Revision - The Object Caching Problem X-Omg-Issue: 51 Date: Wed, 10 Jul 1996 16:54:54 -0700 From: Thomas Wang To: transactions-wg@omg.org Subject: OTS Revision - The Object Caching Problem Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Ed, I have read your description on the object caching problem. Your description ringed a bell with a concept I have been toying recently. The concept is called a 'concentrator'. A concentrator looks like a resource, except its prepare, commit, rollback, and forget function accepts a sequence of resources. A concentrator is similar to a sub-coordinator, except because its participants are tracked by a superior coordinator, it does not need to have local stable storage. A resource wanting to use a concentrator would register itself with the coordinator, but also passing the concentrator object reference along. RecoveryCoordinator register_concentrated_resource(in Resource r, in Concentrator c) raises(Inactive); Two usages immediately comes to mind. First, all resources on a single machine may use a concentrator to lessen cross machine network traffic. Second, a concentrator may flush participants' data to disk before issuing prepare() to them. Regards. -Thomas Wang (Software Engineer, Enterprise Objects Program) wang@cup.hp.com http://www.concentric.net/~ttwang