March 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by mark.little＠jboss.com

"Kevin.Conner(a)jboss.com" wrote : Jonathan, it looks like the real issue may be that a reference to the coordinator is still held by the transaction after the transaction has terminated. | | The transaction impl should disassociate itself from the coordinator on completion. | The transaction is garbage collected when it completes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028046#4028046 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028046

19 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Browser-based configuration editor

by derek.adams

Yep. It will definitely affect the editor. Right now, the upload/download servlets used by the editor assume that there is one config in the conf dir. Is there any kind of API for listing the .esb archives that have been deployed and getting to their contents? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028045#4028045 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028045

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by Kevin.Conner＠jboss.com

Jonathan, it looks like the real issue may be that a reference to the coordinator is still held by the transaction after the transaction has terminated. The transaction impl should disassociate itself from the coordinator on completion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028044#4028044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028044

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by mark.little＠jboss.com

Just an addendum: from a protocol perspective there's no guarantee that afterCompletions will ever be called. They are a courtesy call and failure to produce them won't have an affect on the transaction. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028043#4028043 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028043

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by jhalliday

Sync's are not persisted, so don't get called at all in a recovery scenario if the JVM containing them crashed. In non-crash cases they should be called exactly once. In looking at the code, the collection used to hold the set of Syncs registered for a particular tranaction is explicitly nulled out in the end of afterCompletion processing. However, there is another reference to just one Sync (the last one processed in beforeCompletion) that is not nulled. It therefore won't be colleced until the containing transaction is, although that should not be a problem. I'll add code to explicitly null it out anyhow. Jonathan View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028040#4028040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028040

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by Kevin.Conner＠jboss.com

Synchronisations are not persisted for recovery, only resources, so there is no danger of them being called a second time. The synchronisations should be cleared after the transaction processing is completed though, are you not seeing this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028038#4028038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028038

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Calling Synchronization.afterCompletion() more than once

by bstansberry＠jboss.com

Can a Synchronization's afterCompletion() method be called more than once, e.g in a recovery scenario or something? I'm wondering because I wrote some unit tests that check for classloader leaks following an undeployment. If transactions are used, test shows reference chains leading back to JBossTS via a Synchronization. My assumption is JBossTS releases the ref to the Synchronization in some later cleanup task. Having the test try to figure out when the TM will clean up the Synchronization ref is pretty unworkable, so a seemingly simple workaround was to have the Synchronization null out its state in afterCompletion(). But that's not good if afterCompletion() can potentially be called again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028035#4028035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028035

19 years

1
0
0 / 0

[Design of Security on JBoss] - Re: SASL Authentication

by scott.stark＠jboss.org

We do want to refactor the login modules to only be focused on authentication with roles coming from an authorization phase. For legacy compatibility they still need to be able to pull in the roles where that capability exists. Have you tested the sasl with an ldap server that supports it? I would't think that this could be integrated at the login module level since it tends to come in at the jndi level. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028019#4028019 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028019

19 years

1
0
0 / 0

[Design of JBoss ESB] - Obtaining default ReplyTo EPR

by mark.little＠jboss.com

Currently there's a routine in the code called getTemporaryReplyToEpr. This should really be getDefaultReplyToEpr because that's what it tries to do: in the event a message doesn't have a ReplyTo EPR set, it tries to add a default. WS-A has some well defined rules for this, but only based on SOAP/HTTP, so we have to define our own. The current implementation has some deficienies around JMS, so here's what we're currently considering as an update. Remember, this is for messages that don't have ReplyTo set by the application. First of all, we'd change the name to getDefaultReplyToEpr. 1) getDefaultReplyToEpr will always return an EPR of the same transport type as the one in the argument. 2) JMS will be a queue(or topic) with same name as argument, with a constant appended to the name (e.g., -reply) this assumes that the queue/topic with that suffix exists. 3) JDBC will be a table in the same DB with same name as argument, with a constant appended to the name (e.g., -reply), and the same columns as the original table. 4) File (both local and remote) will be a file in the same directory as arg0, but with a unique reply-name appended to the _inputSuffix. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028011#4028011 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028011

19 years

1
0
0 / 0

[Design of JBoss Portal] - Re: daily build of portal doc

by julien＠jboss.com

great, it's very cool View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4027978#4027978 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4027978

19 years

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