Question

I´m trying to implement session context data for a queued messaging system.

The session handling goes like this:
A front end application authenticates itself and receives a session id.
After that the session id is included in the message headers, so a message handler is provided with a context for e.g. security checks and audit logging. The client may pick up a session if it crashed and continue with it´s work.

So now we want to associate key/value pairs with the session id. But this creates many concurrency problems if the session data changes, as the session data used by the message handler should be that at the time the message was sent.

I see two possible solutions:

1. Put the associated session data in every message header
2. Store the session data versioned to the database and use a version id in the message header.

The first makes messages bigger, the second makes the session DB bigger and creates a lot of infrastructural code. I have to save the most current values to the DB in both, so a client may continue it´s work if it crashed or lost connection.

Are there any other solutions? I tend to use the first solution, but want to get some feedback first.

How do others deal with this (e.g. JMS/NServiceBus/Masstransit)?

Update based on Answer:
I´ve chosen to take the route of convincing my team members to use the session data only in the frontend and putting it into the messages if it is required for the message handler.

Answer 1

You didn’t really go into detail about why you want to associate key/value pairs with the session concept.

Coming from NServiceBus and Udi Dahan’s advice on SOA and service boundaries, this type of session concept tends to rub me the wrong way. My feeling is that message handlers should be, for the most part, fairly deterministic with respect to time. That is, it should run just as well right now, or sit in a queue for awhile and execute the exact same way at some point in the future.

So, my advice would be that for security purposes, go ahead and use message headers if necessary. In NServiceBus you can introduce message handlers from an IT/Ops Service that are configured to execute first in the handler chain, verifying security and stuff like that independent of the actual business logic. In this case, the header information just affects whether the message gets processed or rejected.

When you get to session type information, I would want to carefully analyze those requirements and put the relevant pieces in the message schema itself.

Again, it would be helpful to know the motivation behind the session data in the first place. If you edit your question, perhaps we could identify a way you could reorganize those requirements.