September 2009 - jboss-dev-forums

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

by chtimi2

anonymous wrote : | 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. | But the client does expect a reply: the requests wouldn't be one-way (even when void). To be more concrete by client i mean a Swing client that talks to a server (i feel that by client you mean the client of the RMs, which is our server?). Our application is typically only one AP server, which is a client of several RMs if it can give some context. The RMs and the AP server (which is a client of the RMs) are co-localised (they live in the same VM). I'm going to start thinking about a black-box unit test, to make sure we're talking about the same thing. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255958#4255958 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255958

16 years, 6 months

1
0
0 / 0

[JBoss Web Development] - Re: HttpOnly session cookie flag for JBoss servlets

by francois.petitit

Hello, do you have informations about the availability of this option in JBoss? It has been implemented in Tomcat 5.5.28 and 6.0.19. Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255956#4255956 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255956

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: kernel unit test failures

by alesj

It's this KernelScopeInfo:: updateConstructorAnnotations(repository, (ComponentMutableMetaData) mutable, kernelContext, add); that is the culprit. I've added this code to escape illegal checks against external factory: | // TODO - Kabir check if this is OK? | // we don't handle external factories | if (constructorMetaData.getFactory() != null || constructorMetaData.getFactoryClass() != null) | return; | Although now I get this failures: | testInjectMcBeanIntoField(org.jboss.test.kernel.webbeans.mctowb.test.InjectMcBeansInWebBeansTestCase) | testInjectMcBeanIntoConstructor(org.jboss.test.kernel.webbeans.mctowb.test.InjectMcBeansInWebBeansTestCase) | testInjectMcMethodProducedBeanIntoField(org.jboss.test.kernel.webbeans.mctowb.test.InjectMcBeansInWebBeansTestCase) | testSimple(org.jboss.test.kernel.webbeans.beanwrapper.test.BeanImplementationTestCase) | testDecoratedType(org.jboss.test.kernel.webbeans.beanwrapper.test.BeanImplementationTestCase) Which I need to check if they are related. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255944#4255944 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255944

16 years, 6 months

1
0
0 / 0

[JBoss Cache Development] - Re: Regarding Jboss Cache with Jboss Applicaion Server

by mircea.markus

Take a look here: http://www.jboss.org/community/wiki/JBossCache2xand3xandJBossAS4x Hope this helps. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255941#4255941 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255941

16 years, 6 months

1
0
0 / 0

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

by chtimi2

mark.little(a)jboss.com wrote : | [...] | Thanks for your answers. I still have a few more questions though :) I have looked for references to CheckedAction in the JTS Programmer Guide, and did find a paragraph about async checked transactions. It is at page 51 of the JTS Programmer Guide: Checked transaction behaviour, but after reading it I'm still a bit confused. A/ What are the responsabilities of JBossTS and of the programmer, and how should i override CheckedAction? 1/At page 51 of the JTS Programmer Guide: Checked transaction behaviour anonymous wrote : | Some Transaction Service implementations will enforce checked behaviour for the transactions they support, to provide an extra level of transaction integrity. | The purpose of the checks is to ensure that all transactional requests made by the application have completed their processing before the transaction is committed. | A checked Transaction Service guarantees that commit will not succeed unless all transactional objects involved in the transaction have completed the processing of their transactional requests. | What i understand is that the Transaction Service does the checks. He knows what transactional objects are involved in the transaction. He won't commit before all of them are done processing their transactional requests (so i suppose he blocks until they're done?). 2/Then in the The JBossTS specifics paragraph: anonymous wrote : | By default, JBossTS will issue a warning if a thread terminates a transaction when other threads are still active within it; however, it will allow the transaction termination to continue. | Other solutions to this problem are possible, e.g., blocking the threadwhich is terminating the transaction until all other threads have disassociated themselves from the transaction context. | Therefore, JBossTS provides the com.arjuna.ats.arjuna.coordinator.CheckedAction class, which allows the thread/transaction termination policy to be overridden. Each transaction has an instance of this class associated with it, and application programmers can provide their own implementations on a per transaction basis. | What i understand is that when the transaction tries to commit, JBTS is aware of threads that are still active. But then it's up to the programmer to block the transaction-owning thread until the active threads are done. He does so by implementing a callback (the CheckedAction implementation), that will be called by JBTS before committing the transaction. 3/The javadoc for CheckedAction also says that if you don't override it, the default just prints a warning in case threads still active. And in the source there is this comment on the check method: anonymous wrote : | Called during transaction termination if more than one thread is associated with the transaction. | The supplied information should be sufficient for application specific implementations to do useful work (such as synchronizing on the threads). | But JBTS does know which threads are still active right? Then shouldn't the programmer just need to decide whether to commit now or block? I don't see references to Threads in the parameters of method check, maybe they are in the Hashtable parameter? But isn't it the TS that should be the one blocking them (or not, depending on the policy defined by the programmer's override of CheckedAction)? Otherwise isn't it a bit contradictory (at least in spirit) with the declarative approach of Container Managed Transactions? B/ In the same paragraph, i also don't understand what this means. What does the transaction manager need to be co-located with? anonymous wrote : | Checked transactions are only possible if using a co-located transaction | manager, i.e., the use of a separate transaction manager processes does | not allow checked transactions to be provided by the system. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255934#4255934 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255934

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: kernel unit test failures

by alesj

Yeah, I get this too. Let me have a look at. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255931#4255931 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255931

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: DependencyInfo remove items

by thomas.diesler＠jboss.com

Shows up again in https://jira.jboss.org/jira/browse/JBCL-119 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255930#4255930 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255930

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: kernel unit test failures

by smarlow＠redhat.com

More details from TEST-org.jboss.test.kernel.lazy.test.LazyMetaDataTestCase.xml are here http://pastebin.com/f30843fcf View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255922#4255922 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255922

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - kernel unit test failures

by smarlow＠redhat.com

Is anyone else seeing this unit test failure on kernel/trunk? Failed tests: | testLazy(org.jboss.test.kernel.lazy.test.JDKLazyInstantiationTestCase) | testOnDemand(org.jboss.test.kernel.lazy.test.JDKLazyInstantiationTestCase) | testLazy(org.jboss.test.kernel.lazy.test.JavassistLazyInstantiationTestCase) | testOnDemand(org.jboss.test.kernel.lazy.test.JavassistLazyInstantiationTestCase) | | Tests in error: | testLazyXMLTest(org.jboss.test.kernel.lazy.test.LazyMetaDataTestCase) | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255920#4255920 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255920

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Potential deadlock in ClassLoaderManager

by wolfc

at org.jboss.classloader.spi.base.ClassLoaderManager.unregisterLoaderThread(ClassLoaderManager.java | :128) | - locked <0x95a17ae8> (a java.util.Collections$SynchronizedList) | - locked <0x95a17ae8> (a java.util.Collections$SynchronizedList) taskList == toTaskList View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255911#4255911 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255911

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