I am working  on an application  where 10,000 user will submit a heavy-
weight-request(each request involves updating about 50 rows in DB) to
server in 1 minute. This kind of heavy load  will come to application
once in a month and request processing need not be synchronous.

Initially I thought of using JMS asynch messaging(with JBoss) to avoid
instant huge load on DB. However, I still want to stick to using
Tomcat.

Will appreciate any thoughts from people any design  alternatives
people might have, apart from messaging.

The first thing that comes into the mind is to have a job queue, instead of updating the DB, and the queue is processed in a separate thread. Synchronization among threads is not hard, but should be implemented with enough caution.

Let us know what other design  constraints exist, maybe it needs something more complicated.

You don't need to use jboss or any other application  server if you want to use JMS. There are standalone JMS servers like joram & activemq(I recommend if you want to use open source).
But if you realy don't want to use JMS in your project, You may want to simulate the behaviour of JMS. You can persist your requests and then by another thread(s) fulfil them. Your storage simulates JMS queue and the thread(s) should simulate the behaviour of queue readers.