Issue 631: Possible problem with attributes (transactions) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: usinng explicit transaction propagation, the OTS spec says that programmer must modify signatures of interface mmethods to take transaction context as parameter. How does it work with attributes Resolution: Revised Text: Actions taken: July 21, 1997: received issue Discussion: End of Annotations:===== Return-Path: From: Mark Little Subject: Possible problem with attributes To: transactions-wg@omg.org Date: Mon, 21 Jul 1997 13:44:23 +0100 (BST) When using explicit transaction propagation the OTS spec. says that a programmer must modify the signatures of interface methods to take the transaction context as a parameter. However, how is this supposed to work for attributes, where the user has no control over the signatures which are provided by the idl compilers? As far as I can see, the use of attributes which are required to be transactional will only work with implicit context propagation. If explicit propagation is used, then the signatures of interfaces will have to be modified to remove attributes and add explicit set/get methods instead. This obviously means that some of the idl language effectively becomes unavailable to programmers. Has this issue been raised in the past? Mark. ----------------------------------------------------------------------------- SENDER : Dr. Mark Little, PHONE : +44 191 222 8066, FAX : +44 191 222 8232 Arjuna Project, Distributed Systems Research. POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Return-Path: From: C.Wood@slh0633.wins.icl.co.uk X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 22 Jul 1997 16:00:17 +0100 X400-Received: by mta fel01m2 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 22 Jul 1997 15:57:53 +0100 X400-Received: by mta slh06c1 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 22 Jul 1997 15:57:38 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5-text); Relayed; Tue, 22 Jul 1997 15:57:39 +0100 Date: Tue, 22 Jul 1997 15:57:39 +0100 X400-Originator: C.Wood@slh0633.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;slh0633 0000005000004178] X400-Content-Type: P2-1984 (2) Content-Identifier: 4178 Alternate-Recipient: Allowed To: Juergen Boldt References: <3.0.32.19970721122854.0075b0d8@emerald.omg.org> Subject: RE: issue631 Dr Mark Little writes: > When using explicit transaction propagation the OTS spec. says that a > programmer must modify the signatures of interface methods to take the > transaction context as a parameter. However, how is this supposed to > work for attributes, where the user has no control over the signatures > which are provided by the idl compilers? As far as I can see, the use > of attributes which are required to be transactional will only work > with implicit context propagation. If explicit propagation is used, > then the signatures of interfaces will have to be modified to remove > attributes and add explicit set/get methods instead. This obviously > means that some of the idl language effectively becomes unavailable to > programmers. which leads to issue # 631 > > > Possible problem with attributes > > using explicit transaction propagation, the OTS spec says that > programmer must modify signatures of interface mmethods to take > transaction context as parameter. How does it work with attributes In a brief scan of the transaction service spec, I couldn't find the statement that "the programmer must modify signatures of interface methods". If these words do occur in the document, then this is a slightly unfortunate way of putting it. The point about explicit propagation is that it leaves the propagation of transactions entirely up to the application designer and programmer. Whilst this certainly means having Control (or similar) object references included in some application IDL signatures, one can certainly imagine ways of propagating transactions without adding such references to every op signature. Equally the app designer can take the approach of turning attribute accessors into operations as described in the original e-mail. Of course either of these involves the application designer in additional complexity. Which is precisely why the transaction service specification also offers implicit propagation. I don't see that this is an issue. It is simply a matter of choosing the propagation method that best suits your needs. ---- Chris Wood, ICL Object Software Labs