title: The best way to use a DB table as a job queue (a.k.a batch queue or message queue)
body: <p>I have a databases table with ~50K rows in it, each row represents a job that need to be done. I have a program that extracts a job from the DB, does the job and puts the result back in the db. (this system is running right now)</p>
  
  <p>Now I want to allow more than one processing task to do jobs but be sure that no task is done twice (as a performance concern not that this will cause other problems). Because the access is by way of a stored procedure, my current though is to replace said stored procedure with something that looks something like this</p>
  
  <pre><code>update tbl 
  set owner = connection_id() 
  where available and owner is null limit 1;
  
  select stuff 
  from tbl 
  where owner = connection_id();
  </code></pre>
  
  <p>BTW; worker's tasks might drop there connection between getting a job and submitting the results. Also, I don't expect the DB to even come close to being the bottle neck unless I mess that part up (~5 jobs per minute)</p>
  
  <p>Are there any issues with this? Is there a better way to do this?</p>
  
  <p>Note: the <a href="http://tripatlas.com/Database_as_an_IPC" rel="noreferrer">"Database as an IPC anti-pattern"</a> is only slightly apropos here because </p>
  
  <ol>
  <li>I'm not doing IPC (there is no process generating the rows, they all already exist right now) and </li>
  <li>the primary gripe described for that anti-pattern is that it results in unneeded load on the DB as processes wait for messages (in my case, if there are no messages, everything can shutdown as everything is done)</li>
  </ol>