-
15. Re: Branch 1_0_XARecovery
juha Dec 8, 2006 8:29 AM (in response to juha)"timfox" wrote:
for the acks:
select message_id from jms_message_reference where transaction_id=? and state ="+"
this gives you all the message ids you want to load
Right. This was already in."timfox" wrote:
then call persistenceManager.getMessages(List ids) to get the actual messages for those ids.
This code was duplicated in the original patch and implemented wrong."timfox" wrote:
Then call messageStore.reference(Message m) for each of those messages - this will give you a reference for each of the messages.
Also in. -
16. Re: Branch 1_0_XARecovery
timfox Dec 8, 2006 8:37 AM (in response to juha)Good. As long as you've fixed the problems from the last time I saw the code, that's what matters.
Now, we just need more thorough tests. -
17. Re: Branch 1_0_XARecovery
juha Dec 8, 2006 8:54 AM (in response to juha)"timfox" wrote:
Once you have your references you can call channel.handle(ref, tx) to replay them through the channel.
Now the original patch is assuming a transaction is bound to a single channel. Is that still a correct assumption? -
18. Re: Branch 1_0_XARecovery
timfox Dec 8, 2006 9:00 AM (in response to juha)A transaction can span adds/acks on many channels
-
19. Re: Branch 1_0_XARecovery
juha Dec 8, 2006 9:02 AM (in response to juha)More stuff to fix then.
-
20. Re: Branch 1_0_XARecovery
timfox Dec 8, 2006 9:03 AM (in response to juha)To re-iterate from my previous post:
What you want to do is basically this:
for the acks:
select message_id from jms_message_reference where transaction_id=? and state ="+"
this gives you all the message ids you want to load
then call persistenceManager.getMessages(List ids) to get the actual messages for those ids.
Then call messageStore.reference(Message m) for each of those messages - this will give you a reference for each of the messages.
Once you have your references you can call channel.handle(ref, tx) to replay them through the channel.
(This will create any callbacks).
A similar procedure applies for acks, except the query to get them is different:
select message_id from jms_message_reference where transaction_id=? and state ="-" -
21. Re: Branch 1_0_XARecovery
juha Dec 8, 2006 9:08 AM (in response to juha)You don't have to reiterate. I can fucking read.
What your post is missing is the part that will get me the channel(s) for the transaction. This is currently implemented as returning a single channel ID which is wrong. So that's what I'm looking at. -
22. Re: Branch 1_0_XARecovery
timfox Dec 8, 2006 9:14 AM (in response to juha)"juha@jboss.org" wrote:
What your post is missing is the part that will get me the channel(s) for the transaction. This is currently implemented as returning a single channel ID which is wrong. So that's what I'm looking at.
You can add the channel_id to the selected colums when you retrieve the acks/adds:
select channel_id, message_id from jms_message_reference where transaction_id=? and state ="+" -
-
24. Re: Branch 1_0_XARecovery
juha Dec 8, 2006 9:30 AM (in response to juha)You're thinking a different Open Source group ;-)
-
25. Re: Branch 1_0_XARecovery
juha Dec 8, 2006 3:21 PM (in response to juha)"timfox" wrote:
"juha@jboss.org" wrote:
"timfox" wrote:
1) The call to persistenceManager.associateTxCallbackToPreparedTx() in TransactionRepository::loadPreparedTransactions()
seems to be redundant since the callback will be automatically created when the refs / acks are replayed.
However, removing it will cause the recovery to fail (messages are not delivered).
Should definitely be redundant. If stuff fails when it's removed, then that points to another problem.
So this should be fixed now (along with the correct message retrieval in a tx). That leaves the multi-channel in a tx as next. -
26. Re: Branch 1_0_XARecovery
timfox Dec 8, 2006 3:28 PM (in response to juha)Is this on Branch_1_0?
-
27. Re: Branch 1_0_XARecovery
juha Dec 9, 2006 6:40 AM (in response to juha)Let me fix the channel thing and I'll commit.
-
-
29. Re: Branch 1_0_XARecovery
juha Dec 10, 2006 10:22 AM (in response to juha)Branch_1_0_XARecovery is dead and buried.