<ml>cutting out
some text which I think we agree
on.</ml>
<prf2> ok, late and hidden
enrollments may be trickier - you've re-persuaded me about the inferior-name
qualifier, which can handle the late
case.
hidden (but not late) can be handled
by putting the identifier in the header or equivalent. (this would be
done by the interceptor/filter/... - which surely does know what's going on,
even if it doesn't know
why.
Not
necessarily. The interceptor/filter knows about contexts and threads for sure
and it *may* know about participants, but it need not. In the example I gave, it
didn't need to know (and couldn't know) about participants. It's the same as
what happens in a J2EE environment with, say, an XAResource that is enlisted by
a transaction-aware JDBC driver - all of this happens at the application level
and all the interceptor did was do the thread-to-transaction
association.</ml>
(I privately wondered at one point if
we needed an "inverse-context" - really an inferior context which could be
associated with application messages, in the same way that the existing
CONTEXT (which identifies a superior) is associated. However, when you come
down to it, the content would just be the inferior-identifier, or the
inferior-name if the identifier doesn't exist yet.
)
<ml>Yes, and perhaps we should examine
this.</ml>
That one doesn't use the name at all. The name
allows a sort of indirection, and one might
have
<taxi:confirmationcode
type="btpname">acme-345624</taxi:confirmationcode>
and appearing in the
INFERIOR_STATUSES
<btp:status-item>
<btp:inferior-
identifier>urn:foobar:abcd1234</btp:inferior-handle>
<btp:status>prepared</btp:status>
<btp:qualifiers>
<btpq:inferior-name>
<btpq:inferior-name>acme-345624</btpq:inferior-name>
</btpq:inferior-name>
</btp:qualifiers>
</btp:status-item>
</prf>
<ml>As mentioned in one of the very first
emails on this subject, this isn't a problem if all services are invoked
within the scope of an atom; it's a problem if you call a service directly
within a cohesion. So perhaps we should *require* any non-atom invocations
to specify some "name context" within which participants will be enlisted
(an atom id is an implicit context). So it's down to the sender to specify
something that the decider can then key on later. No name context is illegal
if no atom context is present.</ml>
"sender" is the
service-side application ? Or client-side ?
<ml>Could be both. I was originally
thinking about the client, but there's no reason why the service couldn't be
given this control. Probably should and probably should be the
default.</ml>
It won't generally
help for the client-side to give a name that it expects to see back on the
enrollments arising from that invocation. If there is the possibility of
multiple enrollments, we need to ask if the client will want to choose among
them, or will always treat them as a unit with a single confirm/cancel
decision. If the latter, then the client ought to create its own atom and
propagate that.
Agreed. All of this would go away if we
required services to be invoked within the scope of an atom. But if we don't
want to do that then there's always the possibility that a single service might
enrol multiple participants for a single
invocation.
If the client
wants to choose (or tolerate failures) among the enrollees, then it needs to
know which they are *within* the group, not just that they are part of it.
(obviously there could be exceptions to that - any 2 from N will confirm,
but that's a bit odd). If the service wants to some of its
participants to be treated as units, then it should create a sub-coordinator
to cover them, and enrol that as an inferior to the propagated cohesion -
identified
appropriately.
Again agreed. Some of this may well come
down to "best practices" or "rules of engagement". But we need
them.
That doesn't
preclude a client putting some value on the invocation that will re-appear
as part of the inferior-name though. It seemed that was an application
consideration.though, since its only needed in certain cases.
Mark.
---------------------------------------------- Dr.
Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna
Labs Email: mark_little@hp.com Phone: +44 191
2606216 Fax : +44 191 2606250
|