Re: JMS vs. Home-grown... Which is better in cluster?

I could really use some help on the following question - I need to
figure out if JMS in a clustered environment is really the solution to
my problem...

I have an application that is deployed to a number of servers in a
jboss cluster. I also have a bunch of clients that are writing to a
jms queue in the cluster - they are writing (producing) these messages
very quickly. My understanding is that in a jboss cluster, the queue
isn't really replicated (available) across all servers in the cluster
- which means that every client (producer) gets its jms "message"
piped to a *single* server in the cluster. Is that correct?

My understanding is that if the "designated" jms server goes down,
another node in the cluster will "take its place". Is that correct? If
this is correct it means that as I scale up the number of clients
(producers), they are all going to be trying to communicate with the
one *single* designated jms node. Is that correct?

It seems to me I'd be better off by creating a servlet in my
application that is replicated across all nodes in the cluster - and
this servlet puts the messages into a db table (directly or through
hibernate, etc). This is what JBoss JMS does under the covers
*anyway*, isn't it? It's how JBoss makes the messages persistent,
right?

Then I could have another servlet deployed on *another* cluster of
servers. These servlets would "poll" the db where the messages were
written (by the nodes in another cluster), attempt to mark them as
"consumed" in the db and return them to the caller (consumer) if they
are the one that "got the message". I realize that polling isn't the
greatest solution in the world - but we can always add more nodes to
the "read" cluster and space the polling...

Wouldn't something like this scale better than JBoss JMS clustering?
Why not? It seems like JBoss's JMS solution is great for failover -
but that it just doesn't scale...