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

Reply via email to