Distributed concurrency at the DB or in app code?

I'm writing a distributed program that needs to manage exclusive access to some database rows. Clearly, numerous techniques exist for this case, but trying to KISS. Will this ever scale massively to users? dunno, but I want to plan for some future capacity.

I can't necessarily employ a classic PtP or PnS queue model because this processing will be scatter-gather and optionally synchronous. Layering atop the classic queue models would be possible, but I fear more complicated than necessary. Can you recommend one of the following and why to implement some lower-level control? I have a single DB and n processing nodes.

1. Poll via select for update开发者_运维问答 (or equivalent) for the DB records. There are some who are expressing concern with A) the database contention and B) that polling is still happening.
2. Network synchronized resource lock, persistent connection waiting for processing notifications (been debating an HTTP server push-style...maybe more complicated than layering atop MQ?),
3. UDP message push (with TTL) by single dispatcher?

Any pros/cons or how you've implemented the same in past solutions and did you have the same concerns at the DB sync layer?

Ok, just saw this.

"table as a queue" is quite straightforward. Just use lock hints to control behaviour

There are some subtleties related to what you want to do, but generally a single update with assign or OUTPUT will solve the concurrency bit for you. It works and scales well.