September 2007 - jboss-dev-forums

[Design of JBoss Transaction Services] - TransactionLocal: values, locks and headaches

by jhalliday

A TransactionLocal is similar to a ThreadLocal except it is keyed on the Transaction. Beyond that the documentation is rather sparse. Unlike a ThreadLocal, TransactionLocal is part of the app server, not the standard Java libraries. It?s also pluggable through the use of TransactionLocalDelegate. All this means you can?t be certain of much when it comes to TransactionLocal behaviour. With the switch from the old in-memory TM to the use of JBossTS as the default transaction manager, we also see a new TransactionLocal implementation. Needless to say, it does not work quite the same way as its predecessor. This impacts JBossAS 4.0.x if users retrofit it with the JBossTS, plus all later AS versions since they use the JBossTS implementation by default. The JBossTS version originally (pre-TS 4.2.3.SP6) worked much the same way as the in-memory version: it used a Synchronization registered on the Transaction to store the state of ThreadLocals. This involved WeakReferences, which were suspected of causing more garbage collection load than was desirable. More seriously, there are some nasty corner cases in which it should be possible to change a TransactionLocal but it?s not possible to register a Synchronization. In order to support JTA 1.1?s new TransactionSynchronizationRegistry interface, a generic Object storage mechanism was implemented on Transaction instances. Basically each Transaction behaves as a Map. So TransactionLocalDelegate was reimplemented to use this storage instead of a Synchronization. In JBossTS, javax.transaction.Transaction is implemented by TransactionImple, which has the Map as a member variable. Up until transaction resolution (commit|rollback) a Transaction is represented by the same TransactionImple instance. After that all bets are off ? getTransaction() will generally return a new TransactionImple Object instance on each call i.e. after resolution, Object identity and transaction identity are no longer the same thing. That?s nice for us because it means TransactionLocal state, which is part of the TransactionImple, goes away at transaction resolution time just like it?s supposed to, no WeakRefs required. But? The locks go away too. It?s possible to lock and unlock a TransactionLocal. The lock state is stored in the same Map on the TransactionImple. This is important because in JBossTS, transactions that have reached their timeout are rolled back by a dedicated Thread. Unlike its in-memory predecessor, the reaper in JBossTS won?t try to lock a TransactionLocal before rolling back the Transaction. It?s not required to. So, a transaction may roll back under the feet of a Thread which has done a lock() and therefore expects the TransactionLocal?s value to stay constant. Furthermore, to avoid race conditions you can?t write a TransactionLocal on a terminated Transaction, so that Thread may attempt to update the TransactionLocal and fail. Note that unlock() will fail silent if the transaction has terminated, so calling that is not a problem. The short version: 1) Much of the existing code that makes use of TransactionLocal essentially assumes the behaviour of the in-memory implementation, which no longer holds. In order to support the weaker, more general contract that actually holds for pluggable transaction implementations, it may need more robust exception handling. 2) The pluggable API for transactions in JBossAS should probably be revisited and more thoroughly documented so that I can avoid writing long essays on implementation changes in the future. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087138#4087138 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087138

18 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JAXBIntros moved to JBossWS

by Kevin.Conner＠jboss.com

Great, thanks Heiko. This is definitely the right place to keep it for now. Hopefully we can get it into its own project at a future date. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087127#4087127 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087127

18 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - JAXBIntros moved to JBossWS

by heiko.braun＠jboss.com

It can still be build on it's own, but resides in the JBossWS repository now. I added versionened dependencies to as well. Here you go: http://anonsvn.jboss.org/repos/jbossws/projects/jaxbintros/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087120#4087120 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087120

18 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ManagedObject support in next messaging release

by timfox

"scott.stark(a)jboss.org" wrote : That means that the messaging destinations need to use these mbeans. Currently that is not the case: Right, I'd rather not force people to change their configs - this could be a real hassle. I'd rather just add the annotations to the current classes and live with the necessary imports. When we do the full MC integration as part of JBM 2.0 (i.e. POJOify everything) then we'll be changing everything around anyway and this will result in config changes. We could create the proper integration layer at that stage. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087098#4087098 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087098

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by wolfc

I don't like all the merge logic in the binding classes. Can't we have a separate class hierarchy for that? Then it would become: new MergedJBossMetaData(ejbJarMetaData, jbossMetaData); And standardjboss.xml: new MergedJBossMetaData(standardJbossMetaData, new MergedJBossMetaData(ejbJarMetaData, jbossMetaData)); (it still needs some polishing) And no more the need to ask for merged beans or stuff. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087084#4087084 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087084

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by alesj

"scott.stark(a)jboss.org" wrote : ManagedOperations are never property getters if that is what you mean. They are bean methods that may return a value. | Eh silly me, didn't even think for a second :-(, there are ManagedProperties for that kind of stuff. :-) How do you currently invoke those? Since I think they should be invoked the same way as ManagedOperations - over the KernelBus. That's why we introduced AttributeDispatchContext. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087065#4087065 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087065

18 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: jbossxb mvn test failures

by scott.stark＠jboss.org

If I remove the override of the DefaultHandlers its better, but still bad. run: 636, Failures: 8, Errors: 178 It looks like these are builder failures, and I see them in the original jbossxb-builder project. I did not change any code there, but did update some lib versions so the problem must be coming from that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086974#4086974 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086974

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by scott.stark＠jboss.org

ManagedOperations are never property getters if that is what you mean. They are bean methods that may return a value. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086970#4086970 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086970

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by scott.stark＠jboss.org

I raised this http://jira.jboss.com/jira/browse/JBXB-109 issue which has a failing test. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086968#4086968 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086968

18 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ManagedObject support in next messaging release

by scott.stark＠jboss.org

That means that the messaging destinations need to use these mbeans. Currently that is not the case: | [starksm@succubus testsuite]$ cat ../build/output/jboss-5.0.0.Beta3/server/default/deploy/messaging/destinations-service.xml | <?xml version="1.0" encoding="UTF-8"?> | |  | | <server> | |  | | <mbean code="org.jboss.jms.server.destination.QueueService" | name="jboss.messaging.destination:service=Queue,name=DLQ" | xmbean-dd="xmdesc/Queue-xmbean.xml"> | <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends> | <depends>jboss.messaging:service=PostOffice</depends> | </mbean> | |  | | <mbean code="org.jboss.jms.server.destination.QueueService" | name="jboss.messaging.destination:service=Queue,name=ExpiryQueue" | xmbean-dd="xmdesc/Queue-xmbean.xml"> | <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends> | <depends>jboss.messaging:service=PostOffice</depends> | </mbean> | | </server> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086965#4086965 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086965

18 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 2007