Try PubSub+

.NET best practices for lifetimes/instancing of context/session?

KiwidudeKiwidude Member Posts: 3

We are looking to add Solace support for publishing/receiving from Solace Topics & Queues to our existing .NET C# codebase that already handles MSMQ and MQ. One thing that I have not come across in the documentation / examples is how we should be instancing the IContext and ISession - the code examples simply create one of every object to send/receive a single message and exit which isn't quite a "real world" example :).

For instance with MQ if we wanted to listen to four queues we create four threads each listening to their specific queue and processing their messages. If we were to apply this same pattern to Solace, the question becomes how we should be instancing/sharing across those threads. Should we have a single IContext for our executable process, shared by all listening and publishing threads? Then within that do we have a single ISession shared by all, or should each listening thread create it's own ISession? We also have other code doing publishing - should each thread publishing a message create an ISession/dispose after sending a message or share a single ISession with the listening threads...

Suggestions or pointing me to something I missed would be much appreciated!

Tagged:

Best Answers

Answers

  • KiwidudeKiwidude Member Posts: 3

    Thanks so much for the quick reply - that sounds great. I did "suspect" that may be the answer but for sure wanted some confirmation from yourselves. We are definitely not going to be near high performance range in our usage. All the links are much appreciated too.

  • TomFTomF Member, Employee Posts: 78 Solace Employee

    Glad to help @Kiwidude - if you have a minute, could you mark the question as answered? It would help other users.

  • KiwidudeKiwidude Member Posts: 3

    Sure - if you can tell me how? I'm looking at all the icons and not seeing anything that looks like it would mark that as an answer?
    Still working through those documentation links and thinking about our scenarios/existing code pattern that I am trying to align Solace with. With the current MQ based design we effectively have x threads doing a synchronous read of their specific transactional queues, and if an error occurs on that thread while processing that message the message is left on the queue. This offers protection for temporary network blips to the database during processing for instance.

    The Solace API seems a little "unexpected" from what I have seen so far in that it is the Session that is prescribing the event delegate for handing messages - the Topic or Queue subscribe methods would appear just to be filtering what messages that handler would receive. So having only one session but trying to listen to multiple queues asynchronously would appear to not fit very nicely with our existing application design. Which would then force us into a completely different design like you mention of structures for each broker queue and then threads reading from those - but that sort of design has it's own problems and complications, particularly that at first glance we lose the ability to be semi-transactional. What if our service is stopped with these messages sitting in the interim structures - they will be lost instead of just remaining on their queue etc. Likely I am perhaps missing something obvious...

  • honghong Administrator Posts: 68 admin

    @Kiwidude You posted it as a discussion. That's why you can't accept the answer. Only when you post a Q&A can you accept an answer. I've changed it to Q&A and you can accept the answer now by clicking Yes in "Did this answer the question?".

Sign In or Register to comment.