Have you solved it?
I have a similar issue but I don't want to increase the timeout for the 97% mainstream handling like you....
sorry, but I have no solution. I raised the Transaction Timeout for the EJB Method sending the messages and
accept that sometimes the method will be aborted because of a timeout. In order to avoid the rollback of the successfuly sended messages I use an EJB Method to send one single message with the transaction attribute "requieresNew". This Method is called from the method wich sends all messages.
So the abort of the outer method will have no effect on the messges already sent.
Have you considered breaking up your EJB into two EJBs joined via a JMS queue? Basically have the first EJB generate the messages for the web service, and as it generates say 100 web service requests, it tosses those requests onto a queue instead of making those requests itself. Then have another EJB (MDB) consuming off of that queue and this EJB can have its own custom timeout based on when it should timeout on 100 web service requests.
This lets your first EJB reduce its work load to beat the timeout, and then the other EJB that is doing the web service requests will have its own timeout. Not only that, but since there is the second EJB doing the web requests, you can allow it do run those in parallel and get all your work done much faster and have it broken up with reasonable transaction timeouts.