For the sake of simplicity, let's assume I'm cloning twitter (I'm not). So every user can follow other users, and be followed by other users. For each user you follow, you receive all tweets he sends. Everything is stored in a data storage (be it a NoSQL solution or a sharded relational database).

However, when users *are online*, do you think it is appropriate to have them receive tweets via JMS, rather than polling the database and retrieving new tweets:

* when a user registers (or when he logs-in), a JMS Topic is created, named after him (or his id)
* when a user logs-in he subscribes to the JMS Topic of each of the users he follows
* a session-scoped object (per-user) acts as a JMS message-listener
* all received messages are stored in the session (in-memory)
* the UI is updated via ajax polling of the session-scoped object
* when the user logs-out, or his session times-out, the message-listener is destroyed

The idea behind this is allegedly to boost performance - i.e. not to query the datastore too often, but rather to cache immediate things in memory. 

The whole thing is of course expected to run in a cluster, and be scalable.

However I'm not sure:

* whether this is actually worth it (in terms of performance and scalability gains)
* whether JMS does not add an undesirable overhead, which is equal to querying the datastore (and hence making the whole complication useless)

At some point (when the thing is functional) I will make some benchmarks, but I'd like to hear some initial remarks.