Same message is picked more than once by Nginn.

[megnath777]

We have a scenario where a new message will call the stored procedure which is a long running operation for more than few minutes . (Lets say 10 minutes.)
While that operation is going on the SubQueue status is still 'I' which is fine because its currently being processed.

But however after a minute or so the same message is again picked up by the Nginn. and it calls the SP again.... (Remember the first long running operation is still running)

How can I avoid this duplication call? I tryed to set an additional SubQueue Status 'P' manually (Currently being process.) Hoping that the Nginn would see the status as different from 'I'
So won't pick that up again - When the current long running process is finished Nginn will automatically change it to X /R/F depending on its output.
But that did not work.

Can some one please tell me - How can I avoid this duplication call please ?

I would have thought its a very basic need - I am missing something fundamental here.

Thanking you in advance.
Regards
Mega

[lafar6502]

(from the discussion group)

I suspect this has something to do with the transaction timeout. Each message is received in a transaction and SQL server holds a lock on message record during the transaction so no one else can pick the message. But the transaction can time out and then SQL server will roll it back and release the lock on the message, allowing other thread to handle it again.
Transaction timeout is configured with
MessageBusConfigurator.SetReceiveTransactionTimeout
and by default it's set to 1 minute
I don't know your code and have no idea why stored procedure you mentioned appears to keep going even after the message transaction timed out, maybe it's not a part of same transaction or executes some non-transactional operations - please give more details in next posts, if the problem remains unsolved.

Now you could increase the transaction timeout to say 20 minutes and hope this is enough, but I'm not sure if this is the right solution (usually a transaction should complete in couple of seconds). But please try doing that and see what happens. The alternative way of solving that would be to handle the long-running work in a separate transaction, and only initiate it with a message on message bus (+ monitoring the status/completion and retrying in case the operation is interrupted in the middle).