The design goal is to produce a working dtm that does not make unnecesary inter-vm calls. The functionality of the client side tx interceptor appears to be unavailable with the CORBA OTS if we do not write some client side stuff.
Here is the sequence of events for a call between vms where a transaction is started on the client (could be a standalone app or a JBoss instance) client starts tx client calls ejb proxy client side tx interceptor attaches tx to invocation ONLY if tx support for the method is supports, mandatory, or requires. In all other cases it makes sure no tx is attached to the invocation. invocation is routed to correct transport mechanism (such as by the HA Invoker interceptor)(AFAIK not yet written as an interceptor) Now that we have the target jboss instance determined, the InvokerXAResource enlists with the tx if present, thus getting an xid to transport. If no tx is present, it doesnt enlist with null. The xid is sent over the transport mechanism with the marshalled invocation. The server-side half of the transport mechanism/invoker extracts the xid if present, puts in in an ExcecutionContext, and uses the WorkManager associated with the invoker to execute the call to the ejb. The WorkManager communicates with the server-side tx manager to start and end the transaction at the beginning and end of the call. The method returns. At some later time, the tx commits. Since the InvokerXAResource was enlisted in the tx IF AND ONLY IF the tx was actually sent to do work on the server jboss instance, it will get a commit call only if the server jboss instance actually did work in the tx. If it did work in the tx, it gets (possible) prepare and commit calls with the xid for its branch, and makes a invocation to call an XATerminatorContainer, which has the same method call syntax as an ejb container. In any case it handles communicating the prepare and commit calls to the server-side tx manager. ---------------------- Of course, with optimized in-vm calls, you don't have an InvokerXAResource and don't generate an xid for the method call. ---------------------- Now lets consider the alternative. Without knowing the tx support of every method in the ejb, EVERY transaction MUST be ALWAYS enlisted with the InvokerXAResource, have an xid generated for it, get transmitted over the transport mechansim, and enrolled in the server-side transaction manager. Then when commit comes, totally useless prepare and commit calls must be made to a remote vm for a transaction that COULD NOT POSSIBLY HAVE DONE ANY WORK. We have one remote call to do the requested work and up to two calls to no purpose. It may seem unlikely that a small client would start a user transaction and then call an ejb method that didn't use it, but it seems considerably less implausible to me that a jboss server would call, within a transaction, a remote ejb with a non-transactional method. Looking at the OTS 1.2 spec, I notice that they do not use xids to identify branches. The tx support model appears to only support the equivalent of never, supports, and mandatory. Therefore, if a tx is present in an invocation, either an exception will be thrown or it will be used. Although no xid can be supplied by the OTS, jboss will still be responsible for calling coordinator.register_resource(jboss-resource) back in the corba client. I have no idea how the remote part of corba works, but it would obviously be advantageous to have something analogous to the InvokerXAResource in the client making this call rather than requiring a call back from jboss. david jencks On 2003.02.12 16:31 Bill Burke wrote: > What if you don't have java on the client side? What if you're CORBA > with > OTS? You're making it harder for Non-JBoss/Java clients to integrated > with > us. I think this split should be undone. > > BTW, why the split besides code readability? Is the DTM dependent on > this > at all? Is the TM even accessed on the client side? > > Another problem I see is that the TxMethod map is required on the client > side as well. Makes proxies even more heavy and what do you do about a > hot > deploy? > > Seems to me this is a bad idea. > > Bill > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
