You brought up a good requirement: a MessageListener instance must receive messages in the order published.
My solution: A simple thread-pool worker thread picks up a task in the task queue and calls myListener.onMessage(..). Task queue (being a Queue) maintains the message sequence. (A Task object wraps a listener object and an immutable message object.)
Now, what if one of the onMessage() calls inserts to DB and runs too slow? I would argue it’s “your problem” as the app developer, not “my problem” as the JMS api developer. My job is to call your onMessage() sequentially. I can’t control if the messages go into your DB in sequence.
If 5 messages are found in the task queue, a worker thread should intelligently pick up all and somehow prevent another worker thread from picking up the 6th message (that comes later) and pushing it to myListener before the 5. Essentially, this worker thread should lock on the listener.
I feel in general onMessage() should NOT be synchronized.