On Tue, 21 Jan 2003, David Jencks wrote:
>
> On Tuesday, January 21, 2003, at 09:43 AM, Francisco Reverbel wrote:
>
> > On Tue, 21 Jan 2003, marc fleury wrote:
> >
> >>> And, finally, why did you tightly couple distributed tx logic with
> >>> invoker's implementation? Why is not it possible to write an
> >>> interceptor
> >>> that does distributed tx stuff that you've described but in invoker
> >>> independent way?
> >>
> >> If only ole husgaard was awake :)
> >>
> >> I have been asking the same question for about a year and a half. I
> >> forgot the reason, which probably means it wasn't real, but Ole seemed
> >> to have one...
> >
> > Transaction propagation over IIOP is a reason. CORBA specifies that
> > transaction info goes in the "service context", which is a field of
> > the IIOP request.
>
> Does this constrain non-iiop invokers in any way?
I don't think so. Ideally it would be good if transaction propagation
(i.e. all the code that inserts/extracts XIDs into/from invocation
objects) were somehow encapsulated within a "TxPropagator" MBean,
which would be specified by the contained configuration. Except for
the IIOP invoker, all invokers would use the default TxPropagator
MBean. The IIOP invoker would use an special tx propagator, which
would insert/extract XIDs into/from IIOP service contexts.
The idea of a "default TxPropagator" is similar to our ProxyFactory
notion, in the sense that it works with all invokers but the IIOP
invoker. The 3.2 container config includes a set of "invoker/proxy
bindings". Valid bindings are
IIOPInvoker / IORFactory
* / ProxyFactory (where * is any non-IIOP invoker)
We could have "invoker/proxy/txPropagator bindings" instead:
IIOPInvoker / IORFactory / IIOPTxPropagator
* / ProxyFactory / TxPropagator
Anyway, I don't think the IIOP case should constrain you from doing
whatever needs to be done to have transactions propagated over non-IIOP
protocols. Right now tx propagation over IIOP does not look like a
prioritary thing, so I don't know if an IIOPTxPropagator will be written
or not.
> Do we control anything about the client side of the iiop invoker?
No.
> How about if the client is java rather than c++?
In this case client-side stubs can (but are not required to) be
dynamically downloaded from the server.
> Are there some short yet informative docs on how iiop into jboss works?
No. I am planning to work on doco on February. Right now there is only
the blurb in http://www.jboss.org/developers/projects/jboss/iiop.jsp,
which applies to 3.0. (In 3.2 there were IIOP-related changes on the
container config.)
Do you have specific questions?
Cheers,
Francisco
-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
