"chtimi2" wrote : 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? | Earlier versions of the OTS (prior to 1.4) were very heavily synchronous because that was the emphasis for CORBA. Since then we adopted various message-oriented approaches to interacting with distributed objects and the OTS evolved too. However, the notion of checked transaction semantics does not go away. What happens is that it becomes even more important to enforce it (and difficult) or understand the possibilities if that does not happen. anonymous wrote : | 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. | No, a transaction can be associated with multiple threads at the same time. Checked transactions comes in here too. anonymous wrote : | 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? Some of the functionality is available, e.g., through the CheckedAction class. As to whether it can be used through Spring declarative transactions, I really don't know. anonymous wrote : | 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? | Give me an example. anonymous wrote : | 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? | No, only that the parent-child relationship must be maintained if you want checking guarantees. anonymous wrote : | 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? | Not at all. As long as you have notification somehow that the call has completed, then you can tie that into the checking infrastructure. anonymous wrote : | 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? | It's opaque: they don't see anything unless there is a problem, e.g., a thread doesn't complete on time and in which case the transaction is forced to roll back (better to be safe than sorry). anonymous wrote : | 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=4255874#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...