« - »

Notification Service: To wait or not to wait …

18 November 2008

I’ve been experimenting with different approaches to various issues related to the Notification Service, and one particular issue keeps coming up time and again, and I keep going back and forth as to which is the better approach. When a request comes in to send off x number of notifications, I can either 1) fulfill the request in the current thread and then return to the caller upon successful completion of the process or 2) launch a second thread to asynchronously send out the notifications and then return to the caller without waiting for the outcome of that new, independent process.

The obvious benefit of the second alternative is performance, particularly in cases where there are a number of messages to deliver and/or large blocks of text into which variable data must be injected. Depending on how much work you have to go through to set up the process to be launched in its own thread and how much work must be done once the new thread is released, this performance improvement could be significant, or it could be inconsequential. I am pretty sure, though, that there are definitely scenarios in which it would be quite significant.

The down side, of course, is that you have no way of knowing how successful that process turns out once you release it to run on its own. Sure, there are various ways to have it report back to someone, somewhere, but by that time, the original thread may be long gone and the user moved on to something else. For all intents and purposes, once you spin off a thread to do this kind of work, it’s gone from view. So, the process has to account for that, and have some way to recover in the event of some kind of failure.

One other thing that will impact performance is the point at which you resolve variable data in the message. If all recipients are to receive the exact same message, then you can resolve the message once at the onset of the process, and then loop through the recipient list and send each recipient the resolved message. On the other hand, if each recipient is to receive a message customized just for them, with data for variable replacement coming from the individual recipient objects, then the message resolution must occur inside the loop, once for each recipient. With a large list of recipients, this second approach will be considerably more time consuming than the first. However, it is the only way for each recipient to receive personalized messages directed specifically to them.

So, for personalized messages to a large list of recipients, launching a separate thread is about the only way to do this and still respond back the user in any kind of timely manner. I would imagine, though, that the vast majority of the uses of the Notification Service will be for a single recipient, and spinning off a separate thread would probably be more trouble than it would be worth.

Of course, I guess you could set the service up in such a way that either approach would be an option, and then you wouldn’t have to choose one over the other until run time. That approach certainly avoids the decision, but at the cost of additional work to code for both alternatives. I guess that makes the decision one of three choices: do one, do the other, or do both!


http://blog.restafarian.org/2008/11/notification-service-to-wait-or-not-to-wait/

Leave a reply

You must be logged in to post a comment.