How to avoid concurrency issues when using a database as a communication bus?

Question

Some people tell me that we should avoid multiple apps reading/writing to the same database, because of concurrency issues. They were insistent to the point where they convinced me that a solid architecture only allows a single application to access the database. I don't know if such problems arise from READ operations concurrency, or if they are related only to WRITE operations.

My concern is that the DB is an excelent communication bus for some systems, like the one I'm developing. Are there any guidelines about how to do that while avoiding concurrency issues?

Don't use a database as a communication bus. Use a communication bus for a communication bus. — Oded, Dec 09 '11 at 11:47
@Oded what if the communication bus doesn't the features provided by a database, such as persistency? — Jader Dias, Dec 09 '11 at 12:04

score 4 · Accepted Answer · answered Dec 09 '11 at 11:58

(1) Do not use a database as a communication bus unless you really have to. Given the open source message queuing systems available, I doubt that you do need to.

(2) If you have a transactional database, then concurrent read and write access should be fine, as long as your database has the necessary constraints and triggers to enforce data integritry (and all applications are appropriately tested to ensure in so far as possible that they are not inserting garbage).

(3) If you did not understand (1) or (2), you are not ready to use a database as a communications bus. Go read about databases, concurrency, and transactions.

How to avoid concurrency issues when using a database as a communication bus?

1 Answers1