September 2009 - jboss-dev-forums

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

by mmusgrov

anonymous wrote : I have read the general paragraphs and the ones that talk about asynchronicity in http://www.opengroup.org/onlinepubs/009680699/toc.pdf , | is this the specification you're talking about? I don't see where it says this, then again i didn't understand everything. I was thinking of the XATMI specification http://www.opengroup.org/pubs/catalog/c506.htm which defines how clients and servers interact in a DTP environment and the conditions under which the tx context is propagated. Section 3.5.2 says that if the client issues an asynchronous request and does not expect a reply then the request must not be issued in transaction mode. The client must gather up all replies to his outstanding service requests (the checked semantics refered to earlier in this forum thread) prior to commit. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255889#4255889 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255889

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: DependencyInfo.removeDependsOnMe never called

by alesj

Old discussion about this: - http://www.jboss.org/index.html?module=bb&op=viewtopic&t=101389 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255888#4255888 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255888

16 years, 6 months

1
0
0 / 0

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

by chtimi2

Mmusgrov I'm not sure i understand your answer, let me answer in two parts. "mmusgrov" wrote : This is true in the case of the X/Open Distributed Transaction Processing specifications. Are you saying that the solution proposed by Mark wouldn't work in the case of XA transactions (2PC)? I have read the general paragraphs and the ones that talk about asynchronicity in http://www.opengroup.org/onlinepubs/009680699/toc.pdf, is this the specification you're talking about? I don't see where it says this, then again i didn't understand everything. It does say this: anonymous wrote : 3.3 Association of Threads with Transaction Branches | Several threads may participate in a single transaction branch, some more than once. But does it imply that conversely Several threads may not participate in several transaction branches. Maybe you were thinking of something more explicit elsewhere? "mmusgrov" wrote : The problem with a client starting a transaction and then making an asynchronous call to a remote server is that | the client may call commit whilst the server is still trying to do transactional work. | To cater for this scenario X/Open disallows transaction propagation on asynchronous requests. | This is in contrast to synchronous or conversational requests in which case context propagation is allowed. I don't see why 2PC makes Checked Transactions semantics not applicable: In the solution explained in http://www.cs.ncl.ac.uk/publications/inproceedings/papers/598.pdf, the "root" transaction can commit only after all its "daughter threads" have sent it a completion message. If so, then wouldn't the same solution work in XA just by replacing the global commit (executed on completion of all daughter threads) by a prepare? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255877#4255877 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255877

16 years, 6 months

1
0
0 / 0

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

by mark.little＠jboss.com

"chtimi2" wrote : Questions about the JBTS implementation of this functionnality | | Q'1: | Is there documentation about this topic, or examples specific to JBossTS? I couldn't find a lot in the project documentation (the JTS Programmer Guide). | The docs do talk about Checked Transactions. Also look for CheckedAction class references. anonymous wrote : | Q'2: | Can i continue to use my Spring declarative transactions, with JBTS embedded as the JTA transaction manager? | Haven't tried to, so you can let me know :-) anonymous wrote : | Q'3: | In relation to the previous post, do async services need to be one-way to be able to participate in a multi-threaded transaction? | No. anonymous wrote : | Q'4: | Would this work with JBossPOJOCache as the transactional resource? (i'm not using a database) | None of what was described assumed databases for the resource managers. anonymous wrote : | Q'5: | Any gotchas and things that aren't possible that you can think of? Not off the top of my head. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255875#4255875 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255875

16 years, 6 months

1
0
0 / 0

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

by mark.little＠jboss.com

"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#4255874 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255874

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: DependencyInfo.removeDependsOnMe never called

by thomas.diesler＠jboss.com

This code makes certain assumptions #1 The iDependOn.toString() is the name of the module #2 The other module still exists in the ControllerContext Please verify these assumptions or perhaps this can be done in another way View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255869#4255869 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255869

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: DependencyInfo.removeDependsOnMe never called

by thomas.diesler＠jboss.com

I added this to Module.removeIDependOn | // Remove the DependsOnMe part of this item | Object iDependOn = item.getIDependOn(); | if (iDependOn != null) | { | Module otherModule = domain.getModule(iDependOn.toString()); | DependencyInfo otherDependencyInfo = otherModule.getControllerContext().getDependencyInfo(); | otherDependencyInfo.removeDependsOnMe(item); | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255868#4255868 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255868

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - DependencyInfo.removeDependsOnMe never called

by thomas.diesler＠jboss.com

https://jira.jboss.org/jira/browse/JBCL-119 Consider this BundleA exports A BundleB imports A #1 install BundleA #2 install/start BundleB #3 uninstall BundleB The DependencyInfo of BundleA holds a dependsOnMe entry for BundleB that is never removed. This contributes to the memory leak that we see in [JBOSGI-155] View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255867#4255867 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255867

16 years, 6 months

1
0
0 / 0

[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor

by koen.aers＠jboss.com

The technical discussion should continue on GPD 292. Subtasks of this task may be created to indicate a division of the work. The subtasks can be based on what we already discussed here. - defining additional extension points - refactoring the two classes - creating a preference page to add 'jPDL4 plugins' I agree that the 'Ronald way' is more important and handy. So the first task that is needed is probably the creation of a jPDL4 plugin preference page. The second one is the refactoring of the PaletteFactory to account for these plugins. Regards, Koen View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255866#4255866 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255866

16 years, 6 months

1
0
0 / 0

[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor

by kukeltje

anonymous wrote : So why shouldn't we implement both way's ? Sorry for not making that clear, but that was my intention from the beginning. But I think 'my way' should be done first (although gpd wise you need the other way also) but you do not need to document the way to extend the jpdl core in that case. The "delineation" can be put on a wiki page, but discussing in these kinds of 'broad' jira issues is not good I think. Discussing can either be done in separate topics on the dev forum or on #jbpm on irc.codehouse.org (easy for quick questions). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255863#4255863 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255863

16 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2009