We have a use case where the user can submit 1000 payment transactions(of course in corporate banking this is possible) from a UI.
We all know it is impossible to submit all 1000 from the UI all at once. So we have a pagination logic built in the UI where user can save 200 at once.
After the user finishes entering/saving 1000 transaction, user can do a submit.
When the user submits it because of various timeouts , user experience etc., we store the transaction and current version of the transaction in a batch table and kick of an asynchronous process and inform the user about the asynchronous process. This is working great so far.
Now the requirements came back and want us to increase the transaction limit to 5000. With the current design it is not possible to validate,enrich,transform and insert 5000 transaction in a batch table without a timeout. We cannot make the user wait more than 60 seconds to inform that it is getting processed asynchronously.
We are using Java + Spring + Hibernate + WebSphere combination. The plan is to use Asynchronous bean pool of WebSphere which is nothing but managed threads by the WebSphere. We have used it previously for doing parallel processing and the transaction is managed at the thread level.
The above use case we have for 5000 transaction ,we can use this parallel processing design but the transaction should be managed commonly across threads.
Spring doesn't span transaction across thread. Hibernate is not thread safe.
Only way out is going out of spring and hibernate and manage transaction on your own which is bad design/architecture.
If anyone encountered similar problem(s) or have alternate design approach to solve this issue, your comment/suggestion/help is appreciated.
Submit an article or tip