Fast file logger

[timfox]

Hi Chaps-

Quick question: Does JBoss Transactions have a fast file-based transaction logger component (like HOWL for example).

I'm exploring the idea of how this can help us in JBoss Messaging.

[marklittle]

"have a"? No, sorry. We have several ;-)

There are a number of them (file based, memory/file - for caching, database, etc.) Some of them are optimised for the transaction log so may not be appropriate for your use case. However, some of them are more general purpose, and at least one of them was optimised for the transactional requirements of the Arjuna Message Service implementation.

I assume that at some point you guys will be embedding the core transaction engine from JBoss Transactions in JBoss Messaging in order to get full transactional capabilities? If that happens, you'll automatically have access to these logging implementations.

[timfox]

Great.

Sorry for being lazy - I need to read up on the Arjuna documentation :)

In JBoss Messaging we're currently relying on the fact that the db is recoverable in order to provide our recoverable log.

For 2PC transactions we write the state of our jms transactions into the db on prepare in a single JDBC tx.

For 1PC we just insert the state on commit in a single JDBC tx.

For non transactional reliable JMS sends/acks we end up using a single jdbc transaction for each send/ack.

So as you can see there's currently a tight coupling between the jms transaction and the jdbc transaction.

If we can write to the log to get our reliable guarantee and then checkpoint to the db at some other rate then hopefully we can get some performance gains especially for small JMS transactions or non transational reliable JMS operationns of which several can be checkpointed to the db in a single JDBC transaction.

I guess whether this is faster or not also depends on how fast the databases redo log is and how easily it can be tuned.

Anyhow, I am off to read your docs...

[marklittle]

Even if you don't end up using the logs from JBossTS, you could implement your own that are tied to your specific requirements. I'd definitely recommend moving away from the dependency on the db though - in some cases it makes sense, but in others it can be quicker to use the file system.

[starksm64]

We do have an abstraction that decouples msging from the store. We just dropped the file system version because it was broken. I was going to ask if there was something from the tm we could leverage to restore this, so thanks for querying about this Tim.

[marklittle]

Check out the section on ObjectStore in the various manuals. Let me know if there's anything that you need more information on (though the manuals are fairly detailed).

Mark.