Simultaneous transactions

[robojam]

Hi

I am trying to write an application in VB.NET to process transactions that come down a phone line. As it is possible that one could follow closely on the heels of another, I dont want to have to wait for the first transaction to complete before starting to process the next.

Another programmer is writing the TAPI interface, and I have to provide a function that takes an input string as a parameter. What I need to do is to take the parameter and quickly send it to be processed so that if the function is called again the buffer can be dumped and sent to the called function again.

The MSDN help on threads seems to only help if I intend to run a number of different functions/subs at the same time, and doesnt cover wanting to run multiple instances of the same one.

Can anyone help?

Thanks

 

[Divil]

If what you are using is really that processor intensive, I suggest you read up on the ThreadPool class. It can be passed a delegate to add to a queue of threads, managed by the system.

I havent used this class yet myself so I can offer little more than the advice to look it up and see if its appropriate for your needs.

[mshelp]ms-help://MS.NETFrameworkSDK/cpref/html/frlrfsystemthreadingthreadpoolclasstopic.htm[/mshelp]

 

[Nerseus]

Another possibility is to have a listening app that simply takes each message from the phone line and puts the data into a Message Queue. You can define a Message Queue Listener that calls a component that processes each message. If a message is sent to a Message Queue it can be guaranteed to get in the Queue so you wont have to worry about losing it. Theyre also very fast and made to handle stand-alone transactions that are meant to be asyncronous.

Theyre certainly not right for every situation, especially if youre have a huge volume of messages which might better be processed by your app. Since they can guarantee the message is sent or not sent as a whole unit AND theyre async, they might work for what you want.

I havent used them in .NET but I did in VB6 and they worked like a charm. If you want to investigate them Id first check the .NET support for them. I know the MQ Triggers (the built-in service that called a component when a message arrived) were meant to call COM components. They may have other methods to call .NET assemblies, web services, etc. but I have no idea

Another, similar, alternative is web services. They dont have to be traditional over-the-internet. They could be internal only web services. The advantage they might bring is that they are asyncronous. So your listening app takes the message from the phone line and sends it off to a web service, asyncronously. Ive used web services asyncronously and they work perfectly as well. I dont use them for updates (in async mode that is), but to pull down data in separate threads to speed up the pulling of lookup data, but they do work quite nicely.

-Nerseus

 

[robojam]

Thanks but...

Thanks for the suggestions, but they dont really help me here. Perhaps I didnt give enough details.

Another programmer is dealing with getting the information, and I have to deal with sending each message to be processed, but it has to be possible for a new message to be processed before a previous one finishes to avoid the system coming to a standstill if any third-party systems dont return a message.

I have tried using System.ThreadPool, but it seems to cater for running different program objects at the same time. What I want to do is to run multiple instances of the same class/subroutine or whatever.

Thanks

 

[Nerseus]

I think the suggestions would still work. Let me see if I understand and can re-explain.

It sounds like your app is handling all messages from someone elses piece. You want your app to process each message but not worry about stalling on each message since the processing isnt necessarily something that will complete fast enough. So youre trying to utilize threads to keep your app from stalling on one message.

What I was suggesting was that you would have two apps. One would grab messages from your friends and put the messages in a queue (for example). The Message Queue would instantiate another app, written by you. It would do this for every message it received. This means your second app may get instantiated multiple times (obviously, each one would be in a separate thread - a separate process in fact). Each instance would handle one message only so it wouldnt matter if it stalled.

-ner