Intercept "end of processing"

[nickspacek]

Currently, one of the steps in processing messages takes some data about the message and stores it in a "job context" using ThreadLocals, ala SecurityContextHolder. I'm looking for a clean way to clear that context at the end of processing, regardless of how the processing ends (exception, outbound JMS, another gateway).

It seems like it should be possible to do this, without hooking everything into an explicit channel, but I seem to be missing something. Perhaps the only way to do this IS with an explicit channel (maybe a pub-sub for each path where the message ends)? Seems a little cumbersome though.

[Gary Russell]

It depends on the inbound endpoint. If it's a polled endpoint (or message-driven adapters that support the <transactional/> element - such as the imap idle mail adapter), you can use a 'PseudoTransactionManager', with 'onCommit' 'onRollback' expressions that can invoke a @bean to do the clean up.

For other message-driven adapters, you can put an interceptor on the first channel, and do the clean up in the post-Send - this can do the clean up for "good" results; for exceptions, you'd use an error-channel and do the clean up there.

You can also use this technique for polled adapters (put the error-channel on the poller).

[nickspacek]

The PseudoTransactionManager sounds like the surest solution to me. The reason for trying to do it at the end is that the context information is getting logged and some logging occurs before the messages reach the first channel. It's those first couple messages that look off in our logs. I'll see what I can come up with.

Thanks!

[nickspacek]

Hmm, the approach of using a PseudoTransactionManager seems to be "complicated" by the fact that the input is coming from a JMS listener adapter that has a TransactionManager already. Now I'm down the rabbit-hole of understanding the TransactionSynchronizationManager stuff but can't seem to get a grip on it from Javadoc or the (sparse) available blog entries around the web.

We're already using a subclass of DefaultMessageListenerContainer to generate a selector string for JMS Messages, and from what I gather I need to register my TransactionSynchronization in there somewhere. I can probably fumble through it but not before my deadline. Any advice on where to learn some more about this for the future?

[Gary Russell]

Well, I suggested the PseudoTM only for polled adapters; the message-driven case is much more complex, especially with something that already has transactional semantics such as the JMS adapter.

Yes, it can be done but, as you have discovered, Transaction sychronization is not trivial.

You have to register a synchronization object and the TM will call it during the tx synch. process.

[nickspacek]

Sounds good, thanks for the advice. I took the lame way out in the meantime and hacked it into commitIfNecessary. I will replace it with the sync stuff as soon as possible.