Hi Nick,
If a problem presents itself randomly and the application is threaded, trust me it's a treading issue.
Here what's I've found
You don't lock when counting the queue. Sure you also peek and check for null, but just lock and this step is not needed. The peek step is not threadsafe. One item in the queue. Count step is a pass, peak step passes, or does it. Think about this situation.
One item in the queue
Thread 2 peeks
Thread 1 is blocked, until thread 2 unblocks after peeking,
Thread 1 then deqeues,
Thread 2 then dequeue (going to get null)
Thread 1 sends query (yep I worked)
Thread 2 sends null, (ooops)
logic for your reentrant method.
Setup:
define lock object in a scope both threads can see, such as a field, and set the lock object to a new object.
protected object myLocker = new object();
Method:
lock on myLocker
check queue count
yes, then deqeue
no, then unlock, and return (unlock will be automatic with sync lock in vb... I think)
dequeue item
unlock on myLocker
create new connection (use pooling
have some faith)
open connection
send query
close connection
return from method
Regards,
Pleb