XARecovery: Messaging integration with JBoss Tr...| JBoss.org Content Archive (Read Only)

45. Re: XARecovery: Messaging integration with JBoss Transaction

marklittle May 16, 2006 10:04 AM (in response to mskonda)

"timfox" wrote:
We're not (currently) using distributed transactions.

Actually this makes it even easier then and offers better performance if you got the serializable XAResource route.

We have something like the following:

Transaction Manager on node A (probably an app server) in which we enlist XAresources corresponding to jms servers on (potentially) different nodes e.g B, C

Effectively the XAResource enlist at node A is a remote proxy to the actual resource manager on node B or C (for example).

Doesn't matter as far as the transaction service is concerned. That's an implementation issue for the XAResource provider. As long as something can be used for recovery purposes to complete the transaction, you'll be fine. I would assume a serializable implementation would know how to contact the actual resource managers during recovery, so it shouldn't be a problem.

When prepare is issued on the XAresource this cause a remote call to node B or C, where the state is stored in the jboss messaging transaction log (current ly the db).

If the information about participants is only stored after prepare on node A, then it seems to me that if the node A can crash after the state has been stored on node B but before it has been logged on A.

Yes, that's correct and your architecture does open up the heuristic window of vulnerability. What you could do in this case is flow the transaction context between your proxy XAResource and the "real" XAResource on the remote node in order for recovery to happen. But that's not really a natural way to implement it.

Another alternative is that you write some custom recovery code between the proxy XAResource and the remote resource log. The proxy resource would still be serializable and that's the thing TS recovery would use for transaction-driven recovery. The proxy would need to talk to the backend store and determine what state it is in. So there would need to be some way for it to determine whether the updates were done or not. I'd assume you could figure that out? Obviously this doesn't fix the case where there's no state at the transaction side, but read on ...

In such a case I don't understand how we can use transaction initiated recovery as you suggest, since if we do so, then the transaction manager will never know to rollback the transaction (since it has no record).

What am I missing here?

If you end up in that scenario (the prepared state has been written to the backend datastore but the proxy XAResource wasn't serialized to the transaction log), then you are in the same situation as any other participant state that has no reference to the transaction: you can't know the outcome with surety. So you've either got to make sure your state contains a reference to the transaction coordinator and plug into the Recovery Manager at the state store side (write your own RecoveryModule), or use some heuristic (e.g., "we wait for transaction driven recovery and if nothing's happened after 48 hours we'll flag to a sys admin to figure out, since most failures recovery within that time." and the sys admin will probably end up aborting that state if there is no failure elsewhere). The advantage of the former approach is that it's automatic recovery; the disadvantage is that you need to write more state to disk and implement recovery. The disadvantage of the latter approach is that your not doing automatic recovery in all cases, but you do write less state.

It's a trade-off really. You need to determine how often this type of failure can happen and weigh that off against the effects of adding recovery at the state side.

46. Re: XARecovery: Messaging integration with JBoss Transaction

timfox May 16, 2006 10:13 AM (in response to mskonda)

Seems very complex.

I don't see why we can't just use resource initiated recovery.

We implement XAResourceRecovery (a few lines of code) to get hold of an xaresource (this code already exists), then we're done.

The TM can then call recover() on it and this will return any prepared txs the jms server knows about, so we've avoided the problem of there being no entry in the jboss ts transaction log.

47. Re: XARecovery: Messaging integration with JBoss Transaction

marklittle May 16, 2006 10:17 AM (in response to mskonda)

Where does this XAResourceRecovery instance reside? Which node?

48. Re: XARecovery: Messaging integration with JBoss Transaction

mskonda May 16, 2006 10:19 AM (in response to mskonda)

My XAResourceRecovery instance is deployed on the same node as TM/RM

49. Re: XARecovery: Messaging integration with JBoss Transaction

timfox May 16, 2006 10:20 AM (in response to mskonda)

I was assuming on the same node as the transaction manager (and the remote proxy), i.e. not on the jms server.

50. Re: XARecovery: Messaging integration with JBoss Transaction

marklittle May 16, 2006 10:28 AM (in response to mskonda)

OK, in that case, why can't you stick the intelligence about how to recover into the XAResource? I've been assuming that when it is deserialized from the transaction log, it would be able to connect to wherever the state is held and drive recovery when needed.

Obviously this doesn't help you if the failure resulted in no log entry. But in that case you have to write your own RecoveryModule. Maybe that's where some of the confusion arises. XAResourceRecovery is not something that drives recovery on behalf of a participant: it's used by the transaction to update its stale reference to an XAResource. A RecoveryModule can be used to drive recovery on behalf of a participant and implementations are often tied to the types of participant they work on behalf of.

51. Re: XARecovery: Messaging integration with JBoss Transaction

timfox May 16, 2006 10:37 AM (in response to mskonda)

I feel like we're going around in circles :)

It's my understanding that we cannot guarantee that the tm has a serialized XAResource since the tm node might have failed after the transaction on the server was prepared and logged but before it was logged on the TM node, so relying on serialized XAResources is not an option.

Therefore we need to provide an XAresource somehow that allows the TM to call recover() so it can get a list of prepared txs on the remote node so it can call commit() / rollback() as appropriate.

It was my understanding that XAResourceRecovery is a way of providing that XAResource to the TM.

52. Re: XARecovery: Messaging integration with JBoss Transaction

timfox May 16, 2006 10:39 AM (in response to mskonda)

So in other words, we need to find out is how we provide JBoss TS with this XAResource so it can call recover().

Previosuly we were just sticking it in JNDI so the tx mgr could look it up from there. I don't know if JBoss TS supports this route.

53. Re: XARecovery: Messaging integration with JBoss Transaction

mskonda May 16, 2006 10:58 AM (in response to mskonda)

I don't think as far my knowledge permits (Mark may clarify). The only way I can infer is via XAResourceRecovery interface implementation:

public class MessagingXAResourceRecovery implements XAResourceRecovery{
private Logger _logger = Logger.getLogger MessagingXAResourceRecovery.class.getName());

/**
We must get hold of XA Resoruce at this stage
**/
public XAResource getXAResource() throws SQLException {
 XAResource res = null;
 try {
 Context ctx = new InitialContext();
 XAConnectionFactory cf = (XAConnectionFactory)ctx.lookup("XAConnectionFactory"); //this name can be parameterised
 XAConnection xaConn = cf.createXAConnection();
 XASession session = xaConn.createXASession();
 res = session.getXAResource();
 } catch (Exception e) {
 _logger.info("XAConnectionFactory is not found..will keep trying..");
 }
 return res;
}

public boolean initialise(String param) throws SQLException {
 return false;
}

public boolean hasMoreResources()
{
 return true;
}
}

54. Re: XARecovery: Messaging integration with JBoss Transaction

timfox May 16, 2006 11:03 AM (in response to mskonda)

mskonda - right, so what you have implemented is basically what I was expecting.

At this point, I don't really understand what is wrong with the way you have done it.

55. Re: XARecovery: Messaging integration with JBoss Transaction

mskonda May 16, 2006 11:30 AM (in response to mskonda)

Basic stuff is working currently (I think).
However, prepared transactions aren't logged to object store - I must be doign some thing wrong. There are qutie a few prepared transactions on the Database side too, but none are picked up by the recovery manager. Somewhere something fishy is goign on ..:)

56. Re: XARecovery: Messaging integration with JBoss Transaction

timfox May 16, 2006 12:06 PM (in response to mskonda)

What do you mean "database side"

57. Re: XARecovery: Messaging integration with JBoss Transaction

mskonda May 16, 2006 12:08 PM (in response to mskonda)

That was a distributed tx involving JBossMessaging and Database as two resources.

58. Re: XARecovery: Messaging integration with JBoss Transaction

timfox May 16, 2006 12:11 PM (in response to mskonda)

Forget a database

For your tests you should create a Transaction using the transaction manager and enlist 2 resources in it - one a dummy xaresource and the other a jboss messaging xaresource, as mentioned earlier in the thread.

See XATest for examples, as already mentioned earlier in this thread.

The tests need to be part of the jboss messaging test suite so we can't have any dependencies on MDBs, app servers or other databases.

59. Re: XARecovery: Messaging integration with JBoss Transaction

timfox May 16, 2006 12:12 PM (in response to mskonda)

"mskonda" wrote:
That was a distributed tx involving JBossMessaging and Database as two resources.

You mean a global tx, not a distributed tx. We're not currently using distributed tx.