What is ActiveMQ used for - can we apply messaging concept using a Database?

I looked it up and it used to send messages between 2 systems.
But why? Why wouldn't you just use a Database?
There must be some feature that ActiveMQ has that Databases do not?

Solution 1:

It is used to reliably communicate between two distributed processes.

Yes, you could store messages in a Database to communicate between two processes, but, as soon as the message is received you'd have to DELETE the message, That means a row INSERT and DELETE for each message.
When you try to scale that up communicating thousands of messages per second, Databases tend to fall over.

Message-oriented middle-ware [MOM] like ActiveMQ on the other hand are built to handle those use cases.
They assume that messages in a healthy system will be deleted very quickly and can do optimizations to avoid the overhead.

It can also push messages to consumers instead of a consumer having to poll for the new message by doing a SQL query.
This further reduces the latency involved in processing new messages being sent into the system.

Solution 2:

ActiveMQ, or in general all Message Oriented Middleware (MOM) implementations are designed for the purpose of sending messages between two applications, or two components inside one application.

Essentially, MOM and databases share a common foundation in that they provide transactional and persistent data storage to can read and write from.
The big difference is the usage pattern - where databases are very generic and optimized for complex searching over multiple tables, MOM is optimized for reading messages, one at a time, in a FIFO like fashion [Queue].

JMS, which is an API ActiveMQ implements, is an important cornerstone in Java Enterprise applications. This makes messages share a rather common format and semantic, which makes integration between different applications easier.

Of course, there are a lot of more detailed features that are only in ActiveMQ, wire protocols like OpenWire, STOMP and MQTT, JMS, EIP together with Apache Camel, message patterns like "request/reply" and "publish/subscribe", JMS Bridging, clustering ("network of brokers"), which allow scaling and distributions, etc.
You should read up on those topics a bit if you are interested since they are rather large.

Solution 3:

ActiveMQ has great scheduler support, which means you can schedule sending your message to be delivered at a particular time.

We have used this feature to send medication reminders to patients uploading their medication details in a health care scenario.

Solution 4:

With RDBMS, when you process a row of data, you typically update a flag indicating that the row has been processed so that the processing is not repeated.

However, with Message Queue, you only have to acknowledge a message and the next consumer will process the next one.

The difference is that the UPDATE statment in a RDBMS is a really slow operation compared to the acknowledge in activmeq.

Solution 5:

From Wikipedia

Apache ActiveMQ is an open source message broker written in Java together with a full Java Message Service (JMS) client. It provides "Enterprise Features" which in this case means fostering the communication from more than one client or server

Regarding your queries:

Why wouldnt you use a database?

You should use database for persistent data and not for temporary data. Assume that you have to send a message from Sender to Receiver. On Receiving the message, Receiver execute one operation ( receive , process and forget). After processing that message, you don't need that message at all. In this case, storing the message in persistent database is not a right solution.

I fully agree with @Hiram Chirino answer regarding inserting & deleting message in database if you use database instead of messaging system.

Benefits from this article and this article

1. Enterprise integration : Allowing applications built with different languages and on different operating systems to integrate with each other
2. Location transparency : Client applications don’t need to know where the service applications are located
3. Reliable communication – the producers/consumers of messages don’t have to be available at the same time
4. Scaling – can scale horizontally by adding more services
5. Asynchronous communication – a client can fire a message and continue other processing instead of blocking until the service has sent a response;
6. Reduced coupling – the assumptions made by the clients and services are greatly reduced as a result of the previous 5 benefits. A service can change details about itself, including its location, protocol, and availability, without affecting or disrupting the client.

There must be feature ActiveMQ has that databases dont?

There are many. Have a look at documentation page for more details. Have a look at use-cases too.

Have a look at this presentation to understand internals of ActiveMQ.