Working with JDBC transaction in Netty message processing

Question

I have written an SMPP 3.4 messaging system using Netty 4. Once I have received a new message submission (submit_sm packet) that I am happy to accept onto the platform I write back an smpp response and then write the accepted message onto a local persistent queue (e.g. perhaps a database).

Assuming JDBC as the message store for this example; durability and consistency is key and although I can't wrap both the JDBC insert and the SMPP Socket write into a transaction I do at least want to role back the JDBC insert should the smpp response channel.write operation fail.

My current approach is to maintain a new thread pool that processes the JDBC insert and the SMPP response in a single thread. First I insert the message into the database and then I call channel.writeAndFlush().awaitUninterruptibly() in order to check the operation completed successfully. If the operation failed I can roll back the database transaction.

Does this seem like the correct approach? I can't use a ChannelFutureListener on the ChannelFuture because I need to stay in the same thread so as not to break the transaction boundary. I presume that in my approach there has to be some communication from the IO Thread selected and the thread where I block for the result of the IO operation?

All the best

Jon

Answer 1

Dispatching the received request to another thread pool to handle a JDBC transaction and to call channel.write*() from the JDBC thread is perfectly fine.

One thing to keep in mind is that it is possible that the peer does not receive your response even if your write future is fulfilled. A fulfilled write future only tells you that O/S accepted your write request. The TCP/IP stack of the O/S will try its best to send the response to the peer, but it will eventually fail if the connection is broken permanently.

In such a case, the client will probably re-attempt the request, and it will lead to duplicate transaction. To avoid this kind of cases, you usually have some kind of identifier for each request and the server keeps the list of recent of request IDs to reject duplicate requests.