[clebert.suconic]

https://jira.jboss.org/jira/browse/JBMESSAGING-1418

[clebert.suconic]

"ataylor" wrote:

We also need to test case where recovery occurs without the server being restarted.

I still have some more tests to write which will include this.

We need a super class we could reuse for other similar tests

As you're going through that, that will same me some time later!
(Sorry for being so selfish like that :-P )

[clebert.suconic]

We need a super class we could reuse for other similar tests

I mean... something that will start an INVM Transport, and a fake journal using FakeSequentialFiles (in memory) for quick tests.

[timfox]

We need a super class we could reuse for other similar tests

I mean... something that will start an INVM Transport, and a fake journal using FakeSequentialFiles (in memory) for quick tests.

For most tests you can just use invm transport and null storage manager

[clebert.suconic]

I have done some small changed on XID on Journal.

The Journal should be agnostic about XID IMO, The StorageManager should be the correct place to encode and decode that.

So, I have changed it a little bit. journal.prepare is now receiving an EncodingSupport, and TransactionHolder is aways holding a byte[] representing the XID. JournalStorageManager later will translate that after load is done.


I have also added a few more assertions around Journal tests to make sure the data is handled fine on prepareTransactions.

After this change, you can associate any data related to the prepare. Currently that is being used to store the XID. Even if you start using the Journal in other projects, you still need to record some information supporting the Prepare.

That means.. Prepare still need to support the information about XID, but it can't have any dependency on the XidImpl.

Another option to that would be adding a new record, but you can't do that as ATM the journal can only delete committed records.. you can't add and delete a record in the same transaction.