O termo correto não é antes, e sim ao invés.
O fato é o seguinte: Muitos drivers JDBC (MySQL, particularmente), não usam a metáfora de cursor no servidor, que seria o ideal. Isso pode acontecer por vários motivos (em particular, pelo próprio servidor não oferecer - calma, o MySQL oferece, mas drivers de alguns bancos acabam não fazendo), mas o motivo principal é aquela velha tendência do anaprodégua não chamar o close no resultset.
Ok, dito isso, vamos comentar sobre o seu pobrema. Bem, o que você pretende fazer com os dados, afinal de contas? Se tem tabela temporária, é provavelmente algum processamento oneroso.
Se você tá fazendo isso em uma aplicação web (a julgar pelo WebSphere), minha primeira sugestão é: desvincule isso do request, usando algo como o Quartz, Message Driven Beans, ou o próprio recurso de Asynchronous Beans do WebSphere, como também o de Object Pools.
Em um projeto em particular, lembro-me que o mesmo exigia salvar quantidades absurdas de dados em consultas. A abordagem foi semelhante, mas um pouco mais ortodoxa: O nosso RowHandler lia de uma consulta e… Salvava em outra. Mas a outra conexão era uma base de dados H2.
Pensando bem, uma saída intermediária seria você utilizar o CachedRowSet. Em particular, eu apenas me preocuparia em serializá-lo utilizando Fast-Infoset. Mas, eis, são apenas opiniões minhas. 
