Add transaction scope around postgres ‘find_by_sql’ statement

[nimast]

This is in order to prevent multiple instances of DJ from picking up the same task (as the current locking of FOR UPDATE will suffice for a single connection, when scaled out our workers seemed to have been picking up the same job on different machines)

[coveralls]

Changes Unknown when pulling 723ff09039b310a76f66364866750523309f25c2 on nimast:feature/postgres-reserve-transaction into * on collectiveidea:master*.

[ericcj]

this shouldn't actually be the source of a concurrency problem: http://dba.stackexchange.com/questions/158706/is-a-postgresql-subquery-in-autocommit-mode-part-of-the-same-transaction-or-a-di?noredirect=1#comment304489_158706

http://stackoverflow.com/questions/11532550/atomic-update-select-in-postgres#comment69692209_11568880

[nimast]

@ericcj See the part regarding multiple users in the second post you mentioned. Perhaps serializable isolation level would also fix this issue, but adding a transaction scope solved it too.