Issue 3773: TRANSACTION_UNAVAILABLE standard exception (ots-rtf) Source: ZeroC (Mr. Bernard Normier, bernard(at)zeroc.com) Nature: Uncategorized Issue Severity: Summary: In its updates to the Transaction Service and the CORBA Core, the Messaging final submission (orbos/98-05-06) defines a new standard exception, TRANSACTION_UNAVAILABLE [orbos/98-05-06, 9.2.2] It also defines a single situation where this new standard exception is raised: when the receiving ORB is in the OTS_NOT_CONNECTED state and the request carries a transaction context. It is not clear if an ORB that has never heard of OTS is considered to be always in this OTS_NOT_CONNECTED state, and hence has to check that the requests it receives do not carry a transaction context. If yes, then this checking requirement belongs to the CORBA core, not the OTS spec. And since a compliant OTS 1.1 implementation can propagate tx contexts whenever it can, a positive answer would probably break a number of applications. The messaging final submission defines TRANSACTION_UNAVAILABLE as follows [orbos/98-05-06, 9.5.1.3]: ! TRANSACTION_UNAVAILABLE Exception ! The CosTransactions module adds the TRANSACTION_UNAVAILABLE exception ! that can be raised by the ORB when it cannot process a transaction service ! context because its connection to the Transaction Service has been ! abnormally terminated. This exception is to be defined in Chapter 3 of the ! Common Object Request Broker Architecture and Specification. (Note that in this paragraph the TRANSACTION_UNAVAILABLE is described as a user exception in the CosTransactions -- I consider this a typo!) The strange thing is that the OTS spec specifies (or almost specifies -- see issue #2935) how an OTS implementation registers itself with an ORB (using the TSIdentification interface), but there is no deregister or disconnect operation. How can the ORB find out that the connection to the transaction service has been terminated? Resolution: Revised Text: Actions taken: August 4, 2000: received issue Discussion: End of Annotations:===== From: "Bernard Normier" To: Cc: Subject: OTS-RTF issue: TRANSACTION_UNAVAILABLE standard exception Date: Fri, 4 Aug 2000 15:40:57 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text X-UIDL: LVi!!TeCe9P3b!!)fk!! In its updates to the Transaction Service and the CORBA Core, the Messaging final submission (orbos/98-05-06) defines a new standard exception, TRANSACTION_UNAVAILABLE [orbos/98-05-06, 9.2.2] It also defines a single situation where this new standard exception is raised: when the receiving ORB is in the OTS_NOT_CONNECTED state and the request carries a transaction context. It is not clear if an ORB that has never heard of OTS is considered to be always in this OTS_NOT_CONNECTED state, and hence has to check that the requests it receives do not carry a transaction context. If yes, then this checking requirement belongs to the CORBA core, not the OTS spec. And since a compliant OTS 1.1 implementation can propagate tx contexts whenever it can, a positive answer would probably break a number of applications. The messaging final submission defines TRANSACTION_UNAVAILABLE as follows [orbos/98-05-06, 9.5.1.3]: ! TRANSACTION_UNAVAILABLE Exception ! The CosTransactions module adds the TRANSACTION_UNAVAILABLE exception ! that can be raised by the ORB when it cannot process a transaction service ! context because its connection to the Transaction Service has been ! abnormally terminated. This exception is to be defined in Chapter 3 of the ! Common Object Request Broker Architecture and Specification. (Note that in this paragraph the TRANSACTION_UNAVAILABLE is described as a user exception in the CosTransactions -- I consider this a typo!) The strange thing is that the OTS spec specifies (or almost specifies -- see issue #2935) how an OTS implementation registers itself with an ORB (using the TSIdentification interface), but there is no deregister or disconnect operation. How can the ORB find out that the connection to the transaction service has been terminated? Regards, Bernard Date: Fri, 04 Aug 2000 16:31:04 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Normier Cc: issues@omg.org, ots-rtf@omg.org Subject: Re: OTS-RTF issue: TRANSACTION_UNAVAILABLE standard exception References: <015e01bffe4b$e90abaa0$6a85413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: B*2!!~nj!!AI+e9:g4!! Bernard Normier wrote: > > The messaging final submission defines TRANSACTION_UNAVAILABLE as follows > [orbos/98-05-06, 9.5.1.3]: > ! TRANSACTION_UNAVAILABLE Exception > ! The CosTransactions module adds the TRANSACTION_UNAVAILABLE exception > ! that can be raised by the ORB when it cannot process a transaction service > ! context because its connection to the Transaction Service has been > ! abnormally terminated. This exception is to be defined in Chapter 3 of the > ! Common Object Request Broker Architecture and Specification. > > (Note that in this paragraph the TRANSACTION_UNAVAILABLE is described as > a user exception in the CosTransactions -- I consider this a typo!) You are correct. TRANSACTION_UNAVAILABLE is a standard system exception and it appears as such in CORBA Core 2.4 Draft Chapter 4. Thanks, Jishnu.