Issue 557: WRONG_TRANSACTION (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: OTS 1.1 spec (page 10-17 and 10-18) is not clear whether the WRONG_TRANSACTION exception is intended to be a system exception or a user exception Resolution: issue resolved, see revised text Revised Text: Add a new paragraph at the end of 4.1 as follows. --> Find new paragraph in corresponding archives file Actions taken: April 28, 1997: received issue June 20, 1997: closed issue Discussion: End of Annotations:===== Return-Path: Date: Fri, 25 Apr 1997 16:47:48 -0700 (PDT) From: Alan Snyder Reply-To: Alan Snyder Subject: clarifications needed on OTS exceptions Cc: orb_revision@omg.org Errors-To: owner-orb_revision Sender: owner-orb_revision X-OMG: orb_revision To: orb_revision Issue 2: The OTS 1.1 specification (page 10-17 and 10-18) is not clear whether the WRONG_TRANSACTION exception is intended to be a system exception or a user exception. Evidence for a user exception: 1. The OTS specification describes only two uses for this exception, which involve the get_response() and get_next_response() operations. There is no suggestion that all request invocations might raise this exception. 2. The exception does not have an "ex_body", as do the other three exceptions. 3. The other three exceptions are labelled "standard exceptions"; this one is not. 4. The other three exceptions are noted as being defined in Section 3.5 of the CORBA specification (I think it should be 3.15), this one is to be defined in Section 4.3.3. 5. Ed Cobb told me that he intended it to be a user exception. Evidence for a system exception: 6. The OTS 1.1 specification changed the exception name from WrongTransaction to WRONG_TRANSACTION. In the CORBA module, upper case names are used for system exceptions and mixed case names are used for user exceptions. Comment: I believe that (6) results from a misunderstanding on the part of the OTS RTF. I think they were not aware that the CORBA module already had user exceptions. I believe that the intent was that ordinary request invocations in general should not raise the WRONG_TRANSACTION exception. Proposed resolution: As a general principle, system exceptions should be used only for exceptions that any request might potentially raise. Because the WRONG_TRANSACTION exception is not intended to be raised by all requests, but only by get_response() and get_next_response(), it should be defined as a user exception. For consistency, it should be renamed to WrongTransaction. Specific changes: (1) Move all but the first and the last paragraph of the marked text on page 10-17 of the revised transaction spec (Nov 22, 96 Draft) into section 4.3.3, after changing the name of the exception to WrongTransaction. (2) Add the last paragraph from the marked text to section 4.3.4. (3) Make sure that the declaration of the WrongTransaction exception finds its way into the IDL for CORBA module at the appropriate place (i.e. before the ORB and the Request interfaces. Alan Snyder #557 CLOSED Sections 4.1, 4.2, 4.3.3, and 4.3.4 Comment: OTS 1.1 spec (page 10-17 and 10-18) is not clear whether the WRONG_TRANSACTION exception is intended to be a system exception or a user exception. Resolution: Add a new paragraph at the end of 4.1, as follows: "The user exception WrongTransaction is defined in the CORBA module, prior to the definitions of the ORB and Request interfaces, as follows: exception WrongTransaction {}; This exception can be raised only if the request is implicitly associated with a transaction (the current transaction at the time that the request was issued)." In 4.2, change the third line from the bottom of the PIDL from "):" to ") raises (WrongTransaction);". In 4.3.3, change the last line of the PIDL from ");" to ") raises (WrongTransaction);". Note: This was fixed by #401. Add a new paragraph at the end of 4.3.3, as follows: "A request has an associated transaction context if the thread originating the request had a non-null transaction context and the target object is a transactional object. The get_response operation may raise the WrongTransaction exception if the request has an associated transaction context, and the thread invoking get_response either has a null transaction context or a non-null transaction context that differs from that of the request." Add a new paragraph at the end of 4.3.4: "A request has an associated transaction context if the thread originating the request had a non-null transaction context and the target object is a transactional object. The get_next_response operation may raise the WrongTransaction exception if the request is associated with a transaction context, and the thread invoking get_next_response has a non-null transaction context that differs from that of the request."