Often times this kind of thing is not handled "live". The user is tied up and cannot navigate away, a close of the browser can cause issues, etc.
If I had to do this kind of thing in the portal, I'd likely be sending a message to a receiving component, makes the processing of the message asynchronous in nature.
Upon completion, I'd likely leverage the notifications API to send a notification to the user. Will sit in the notification queue waiting for the user to log in and review it. In fact, you could send to a role or a group if you needed to notify more than just a single user or you want to ensure the process will continue to work even if the user leaves the organization.
But honestly I'd actually push back on this requirement. Any long running batch task running inside tomcat and inside the jvm is going to suck memory, cpu cycles and other resources away from the portal instance, away from the primary responsibility of servicing user requests.
Even if it had to be running within a portal context, I'd probably still lean towards running this in an isolated cluster node; one node would be out of the cluster (via load balancer config), not serving user requests but only servicing these kinds of batch tasks. This would leave the cluster up and running to service user requests.
