September 2006 - jboss-dev-forums

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?

by adrian＠jboss.org

I'm not implementing a TM, I'm implementing an heuristic resource with a local branch log. JMS is a remote resource. e.g. If a JBossMessaging server gets enlisted by a transaction manager on a machine that explodes and the log is lost then you need a mechanism to put the messages back in the queue. The exploded tm is never going to recover. :-) There are other reasons why the TM might not complete the transaction (e.g. network outage) and you need to get the messages processed even if it means an heuristic. Its the same issue as when you need to clear db locks when a server crashes holding the locks and it can't be recovered. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972279#3972279 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972279

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?

by timfox

"mark.little(a)jboss.com" wrote : | Aren't you going to have to do this anyway if you have a crash failure, given that the map is in volatile store? Yes. The map will be repopulated on server startup with the state of any prepared txs from the log (db). So I guess this is a non issue- we just do the same if the tx instance is not found in the map. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972272#3972272 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972272

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?

by mark.little＠jboss.com

"adrian(a)jboss.org" wrote : "timfox" wrote : | | If I don't remove the instance then I get a memory leak. | | | | You only have a memory leak if the number grows large. | Which you can give a warning about anyway. | if (map.size() > 100) | log.warn("Your TM is probably broken!"); | | The usual solution is to move the transaction to an "in doubt" state | after a configurable period of time. e.g. 1 hour | or if you have to recover after a failure. | It should definitely try to optimise for the non-failure case. However, it sounds like you're implementing a transaction manager here, so my next question would be: why? Why can't you just use the one that is available in whatever the deployed environment happens to be? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972269#3972269 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972269

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?

by mark.little＠jboss.com

"adrian(a)jboss.org" wrote : "timfox" wrote : | | If I don't remove the instance then I get a memory leak. | | | | You only have a memory leak if the number grows large. | Which you can give a warning about anyway. | if (map.size() > 100) | log.warn("Your TM is probably broken!"); | | The usual solution is to move the transaction to an "in doubt" state | after a configurable period of time. e.g. 1 hour | or if you have to recover after a failure. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972268#3972268 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972268

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: MessageService and JMS

by tom.baeyens＠jboss.com

try the following two extra steps in advance of the given scenario: -1) delete the ${user.home}/jbpm/repository/jbpm directory. actually the clover subdirectory doesn't have to be deleted. but the other directories might contain old versions of snapshot builds that are used instead of the newly stuff that is build from the sources. 0) do ant get.dependencies in the build/build.xml let me know if that helps View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972267#3972267 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972267

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?

by adrian＠jboss.org

"timfox" wrote : | If I don't remove the instance then I get a memory leak. | You only have a memory leak if the number grows large. Which you can give a warning about anyway. if (map.size() > 100) log.warn("Your TM is probably broken!"); The usual solution is to move the transaction to an "in doubt" state after a configurable period of time. e.g. 1 hour or if you have to recover after a failure. Then provide a mechanism for the administrator to resolve these heuristically. You need to record permenant storage the result of these heuristics so you can give the correct response if you do get the commit/rollback. You could also get a forget(). But this is a 0.1%/99.9% case. Having to go to the db to get the heuristic state or the state of an in doubt transaction is not a real an issue. If the state isn't there, you are going to throw an exception anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972266#3972266 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972266

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?

by mark.little＠jboss.com

"timfox" wrote : I was hoping you were going to answer :) | Given the amount of corporate spam we get, sometimes email is easier ;-) anonymous wrote : | We currently log prepared states in the db (this will change). | | So after the prepare has completed the prepared state has been logged durably. | | The thing in memory is our "Transaction" class, which has methods prepare(), commit(), rollback() etc. | | When a prepare comes in we add the Transaction instance to the in memory map. | | This means that when we receive a subsequent commit/rollback we look in the map, get the instance and call commit/rollback on it. | | This then moves the prepared state from the log to permanent storage. | | So, if I remove the Transaction instance from memory after commit/rollback irrespective of whether an exception occurs, then if another commit/rollback comes in without recover (recover repopulates the map from the log) it won't find it. | | If I don't remove the instance then I get a memory leak. | | AFAICT the solution here is to repopulate the map if a commit/rollback comes in and it isn't in the map - which is a bit of a pain.... Aren't you going to have to do this anyway if you have a crash failure, given that the map is in volatile store? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972263#3972263 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972263

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?

by timfox

I was hoping you were going to answer :) We currently log prepared states in the db (this will change). So after the prepare has completed the prepared state has been logged durably. The thing in memory is our "Transaction" class, which has methods prepare(), commit(), rollback() etc. When a prepare comes in we add the Transaction instance to the in memory map. This means that when we receive a subsequent commit/rollback we look in the map, get the instance and call commit/rollback on it. This then moves the prepared state from the log to permanent storage. So, if I remove the Transaction instance from memory after commit/rollback irrespective of whether an exception occurs, then if another commit/rollback comes in without recover (recover repopulates the map from the log) it won't find it. If I don't remove the instance then I get a memory leak. AFAICT the solution here is to repopulate the map if a commit/rollback comes in and it isn't in the map - which is a bit of a pain.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972261#3972261 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972261

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?

by mark.little＠jboss.com

"timfox" wrote : My question is this: If commit or rollback throws an exception is it valid for the transaction manager to retry the commit or rollback (without first calling recover)? | Yes, it is valid in some cases. However, depending upon the error, it may not be worthwhile. anonymous wrote : | If I can assume the commit/rollback is never retried then I can safely remove the transaction state from the map in a finally block, whether or not the commit or rollback succeeded. | | If not, then I cannot see a safe time when the transaction state can be removed from the map. | Is this durable data? Will it survive a failure (I assume so, but need to ask). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972258#3972258 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972258

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?

by timfox

If so, then that means we would have to force recovery if a commit/rollback comes in and we can't find it in the in memory map View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972257#3972257 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972257

19 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 2006