JMS and messaging is really about 2 totally different things.
- publish and subscribe (sending a message to as many consumers as are interested – a bit like sending an email to a mailing list, the sender does not need to know who is subscribed
- high performance reliable load balancing (message queues)
See more info on how a queue compares to a topic
The case you are talking about is the second case, where yes you can use a database table to kinda simulate a message queue.
The main difference is a JMS message queue is a high performance highly concurrent load balancer designed for huge throughput; you can send usually tens of thousands of messages per second to many concurrent consumers in many processes and threads. The reason for this is that a message queue is basically highly asynchronous – a good JMS provider will stream messages ahead of time to each consumer so that there are thousands of messages available to be processed in RAM as soon as a consumer is available. This leads to massive throughtput and very low latency.
e.g. imagine writing a web load balancer using a database table 🙂
When using a database table, typically one thread tends to lock the whole table so you tend to get very low throughput when trying to implement a high performance load balancer.
But like most middleware it all depends on what you need; if you’ve a low throughput system with only a few messages per second – feel free to use a database table as a queue. But if you need low latency and high throughput – then JMS queues are highly recommended.