Daft question of the day - why lock queues?

[john.hammond]

This is probably a very daft question, but myself and a few other recently appointed developers have been playing around with different architectures, and have been encouraged to lock the queue prior to loading a queue and then reporting.

I'm just wondering specifically why these queue locks need to be put in place? I understand that an item lock should be put in place so that if a process utilises multibotting, only one bot can process one particular item. But we've been able to load a queue with one process whilst another process has drawn something from that queue and processed it successfully without a lock. So where would locks need to be put in place if we're just dealing with a single process accessing a single queue? And why?

Can somebody clarify this for me please?

------------------------------
John Hammond
------------------------------

[ewilson]

Hi @john.hammond,

When you say you're being encouraged to "lock the queue" do you mean through the use of the Environment Locking VBO? The only reason I can think of to try and lock the entire queue is if you had a process that was trying to perform some sort of cleanup or administration of the queue which required it to be stable/consistent (no new adds, completes, deferrals). ​Otherwise, the built-in locking mechanism associated with Get Next Item should be sufficient IMHO.

Perhaps someone else will chime in and tell me why I'm mistaken. 🙂

Cheers,

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------