[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] Deferred BTP Issue 108 : Participant and serviceidentification
<ml>Assuming the above is on a response from a
service then that's fine. However, it does now require that that information is
now know about by the service. It may not be. The service may not actually know
about its participants since the enlistment may not happen at reception of the
incoming request. All that may happen at that point is the thread-to-tx
association. Participant enlistment may not happen until much later (if at all)
when some transactional work is done (i.e., work that is required to be
controlled by a coordinator). Now the thing that does the enlistment may not be
known about to the service or the BTP interceptor/filter/you-know-what-I-mean.
An example of this would be how JDBC 2.0 drivers do enlistment of XAResources
under the covers from the application that uses them such that the
application/EJB doesn't know its happened and can't get access to that
information anyway.
We want to be able to support the above scheme since we
believe many services will be transaction unaware at he business logic level and
where the enlistment occurs is a configuration/deployment/implementation choice.
Now I'm not saying that the participant information can't be available to be
returned to the invoker, only that we can't assume it will be. So, we need some
way for a decider to get this information. Calling inferior_statuses will always
return a list of participants and could be used to figure out what has "just"
been enlisted. Obviously this could be done by the service on the outward call
to fill in the blank above if it doesn't normally have direct access to the
participant information or it could be done by the caller. Runs some risks
though since one outward invocation may cause may participants to be
registered.</ml>
<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>
Mark.
----------------------------------------------
Dr. Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.com Phone: +44 191 2606216 Fax : +44 191 2606250 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC