1. No, you can probably work something out using a UserTransaction.
2. I didn't know about that... You could fork a thread to receive.
3. Your best bet might be use a message selector to aggregate, then ACK the last message, however if the queue grows substantially, you're not going to have good performance.
Another technique would be to continuously read until all sets are aggregated, then ack the Session. It may be hard to reach a boundry in some cases.
Unfortunately, you can't ACK part of a set of messages received from a session. You can also try to create a large number of sessions, one per message.
It took me a few minutes to figure out what you were proposing and then I realized that what I need is simpler than the example I referenced from the EAI patterns book. In my application there is only one type of aggregate. Thus, I don't have to worry about not being able to ack messages in a completed aggregate when there are still messages in another unfilled aggregate.
I managed to get working solution using blocking receive() calls. It seems to work well, but I haven't stress tested it. If someone would like me to post it on the Wiki or elsewhere, please send me a private message.