[SOLVED] Making code in Liferay Model Listeners Asynchronous (using concurrency)

Making code in Liferay Model Listeners Asynchronous (using concurrency)

The Problem

Our liferay system is the basis to synchronize data with other web-applications.
And we use Model Listeners for that purpose.
There are a lot of web-service calls and database updates through the listeners and consequently the particular action in liferay is too slow.

For example: On adding of a User in liferay we need to fire a lot of web-service calls to add user details and update other systems with the userdata, and also some liferay custom tables. So the adding of User is taking a lot of time and in a few rare cases the request may time-out!
Since the code in the UserListener only depends on the User Details and even if there is any exception in UserListener still the User would be added in Liferay, we have thought of the following solution.

We also have a scheduler in liferay which fixes things if there was some exception while executing code in Listeners.

Proposed Solution

We thought of making the code in UserListener asynchronous by using Concurrency API.

So here are my questions:

Is it recommended to have concurrent code in Model Listeners?
If yes, then will it have any adverse effect if we also update Liferay custom tables through this code, like transactions or other stuff?
What can be other general Pros and Cons of this approach?
Is there any other better-way we can have real-time update to other systems without hampering User-experience?

Thank you for any help on this matter

Solution

It makes sense that you want to use Concurrency to solve this issue.

Doing intensive work like invoking web services etc in the thread that modifies the model is not really a good idea, apart from the impact it will have on user experience.

Firing off threads within the models' listeners may be somewhat complex and hard to maintain.

You could explore using Liferay's Message Bus paradigm where you can send a message to a disconnected message receiver which will then do all the intensive work outside of the model listener's calling thread.