Database as IPC antipattern

views:

answers:

+2 Q:

Database as IPC antipattern

Hi,

I've written a layered web application that consists of a rich-web client (PHP) that interacts with a java service. The web client is hosted on an apache server, and the java service runs on the same physical machine (to reiterate: the entire app, client and service, are running on the same physical machine).

User Request --> DB <-- Poller --> RequestHandler --> StoreResult in DB --> Web Client updates page with the result (AJAX).

Communication between the client and service uses a relational database to pass messages. The java service has a single-thread poller, which looks for and then processes any messages/requests from the client. The system works, but I am not confident in my design choice.

Does anyone have any comments about this strategy? I've read that using a Database as IPC antipattern is poor practice, or at least an inappropriate one. However, the alternatives--XMLRPC, named pipes--seem to involve additional dependencies.

Thanks for looking.

I see following arguments for DB as IPC:

1)You need to store all (or for some period) messages you ever received.

2)You need high reliability and don't want to loose any messages.

3)Perfomance of DB opposite sides is very different. In this way left client side can generate huge amount of messages and many clients on right side will process them. So DB is like passive load balancer with high reliability.

Do you need any of this features? I think no. You can't use it as load balancer because all processes are on the same host. And I think that you don't need to store all web requests.

In this case I would choose simple sockets.

Donz 2010-09-28 19:10:54

Valid points. So, for sockets the client would need to open a socket and send it's message to the java service. Therefore, I would need to write code to manage the server sockets. How efficient is this? And what of reliability--the server socket crashing, etc. Also, how expensive would it be to open a client socket for every user request? Thanks for your suggestion.

meta.matt 2010-09-28 19:28:12

Donz 2010-09-28 19:44:35

Do your really need not to loose even one message? For web apps it's normal not to deliver some requests. User see an error and tries one more time. So generally you don't need high reliability for web apps. When you connect to DB you use sockets too but on higher level protocol. So you can reach more efficiency with raw sockets. If you don't want to reinvent the wheel you can use HTTP request from one service to another. Even with HTTP you will utilize less CPU and memory that with DB. Main point - understand prevailed features you really need and choose the appropriate protocol(or may be DB)

Donz 2010-09-28 19:50:38

It is a hack, but it obviously works for you. Here is a web site on how to implement a message queue with a DB table in PHP.

Romain Hippeau 2010-09-28 21:28:07

If you just need message passing for PHP, just use ActiveMQ - just like message queues in UNIX IPC. However database may be a good equivalent of shared memory and semaphores known from UNIX IPC. So having ActiveMQ and database you can do the same you would be able to do with UNIX IPC, but it can be clustered if one server will be too little for you.

iirekm 2010-10-12 08:32:08

ansaurus

tags:

views:

answers:

Database as IPC antipattern

related questions