Cannot attach method specific transaction intents

XMLWordPrintable

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major
    • None
    • Affects Version/s: V1.1
    • Component/s: 1.1 Spec
    • None
    • Hide

      Informally, a proposed resolution would look something like this:

      The technical solution would be adjust POL90028, POL90029 and the corresponding tests in the test suite. For example, POL90028 could be re-written something like this...we can argue about the precise words later:
      The transactedOneWay intent MUST be ignored by the runtime for a request/response operation. [POL90028]
      We'd make a similar fix to POL90029.
      The test suite tests would change to ignore the intent as appropriate instead of raising an error as they do today.

      Show
      Informally, a proposed resolution would look something like this: The technical solution would be adjust POL90028, POL90029 and the corresponding tests in the test suite. For example, POL90028 could be re-written something like this...we can argue about the precise words later: The transactedOneWay intent MUST be ignored by the runtime for a request/response operation. [POL90028] We'd make a similar fix to POL90029. The test suite tests would change to ignore the intent as appropriate instead of raising an error as they do today.

      Section 9.5.2 in the Policy spec has this normative statement;
      The transactedOneWay intent MUST NOT be attached to a request/response operation. [POL90028]
      The problem with this statement is that it is too strict. If you read the three preceding statements:
      When a reference is marked as transactedOneWay, any OneWay invocation messages MUST be transacted as part of a client global transaction. [POL90008]
      If the client component is not configured to run under a global transaction or if the binding does not support transactional message sending, then a reference MUST NOT be marked as transactedOneWay. [POL90009]
      If a service is marked as transactedOneWay, any OneWay invocation message MUST be received from the transport binding in a transacted fashion, under the target service's global transaction. [POL90010]

      You can see stmts 8, 9 and 10 consider the fact that this intent might be attached at locations where there are both oneway and request/response operations. POL90028 does not have the same conditional behavior, and as a result, prohibits this intent from being placed on an interface/service/reference which has both one-way AND request/response operations.

      We have the same problem with immediateOneWay intent. Those statements immediately follow in section 9.5.2.

            Assignee:
            Unassigned
            Reporter:
            David Booz (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated: