[jboss-dev-forums] [JBoss Transactions Development] - Re: Asynchronicity and transaction context propagation

[chtimi2]

Questions and comments about the article
I quote excerpts of the article, and add my questions or comments in italic. The comments might well be wrong, by all means feel free to tell me so.



anonymous wrote : 1. Introduction

anonymous wrote : Although protocols exist for enforcing thread and transaction synchronisation in local and distributed environments (commonly referred to as checked transactions [1]), they assume that communication between threads is synchronous (e.g., via remote procedure call). A thread making a synchronous call will block until the call returns, signifying that any threads created have terminated. 
  | For example, the Object Transaction Service (OTS), specified as one of the Common Object Request Broker Architecture (CORBA) Services [2] by the Object Management Group, specifies a checked transactions protocol based upon the X/Open model.

Q1:
Doesn't this mean that OTS in intrinsically synchronous? But then isn't this synchronicity contagious up to JTS/JTA? 
On the other hand other readings seem to indicate that the JTA/JTS specifications don't forbid or mandate support for the scoping of a transaction context to several threads.
The question is then, is JBTS support of this functionnality accessible through standard JTA interfaces? For my personal case, would it work with declarative transactions in Spring?


anonymous wrote : 2. A processing model
This looks compatible with what we would need.



anonymous wrote : 3. Checked behaviour
Checked means that when the initiating transaction has committed, the commit includes the actions of the "sub-threads".
Transactions within a single thread are always checked, multithreaded transactions require additional controls to be: completion callbacks go up the thread creation hierarchy up to the root thread, the one that initiated the transaction.
Only then is the transaction committed, even though control has already been given back to the client of the root transaction.

Q3:
Can the client have some sort of Future or does the operation have to be one-way? 
Can he be notified of the transaction outcome?

anonymous wrote : and the transaction 'end' may not proceed until the thread created for the invocation upon object a returns a 'synch'.
This is coherent with the notion of a checked transaction.
anonymous wrote : The thread created by the invocation upon object a cannot terminate until the thread it created for the invocation upon object b returns a 'synch'; 
Q4:
But this seems stranger. Doesn't it mean that the invocation of b by a is synchronous?



anonymous wrote : 4. The application domain

anonymous wrote : Asynchronous invocation is implemented as a CORBA 'one-way' call.
Q5:
Does this mean checked async transactions lony work with void one-way calls, and that the client can't get a Future?



anonymous wrote : 5. Using the CORBA Object Transaction Service

anonymous wrote : Instead our proposed implementation dynamically turns asynchronous invocations into deferred synchronous, 
  | if and only if, the invocation is occurring within a transaction. 
  | This modification to the invocation mechanism occurs at runtime, and is completely transparent to the programmer.
Again, what does this mean for the caller of the root service that initiates the transaction?
Doesn't deferred synchronous mean you get a blocking Future reference (or something else, but that holds a return value)?
Isn't that contradictory with the other times when they say the async methods need to be one-way? I'm confused.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255768#4255768

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255768