I don't know that I'd do this inside of a model listener. I mean, conceivably it should work, but typically I look at a model listener to make a change to the current entity or perhaps mirror some or all of the current entity out to some other table or entity.

But I wouldn't look at it as the point to retrieve and update other entities of the same type. Because as you update those, well the model listener is going to get triggered on those, and pretty soon you're left trying to decide if you should apply the update or not within the context of a model listener and things get really messy.

For what you want to do, I'd actually use a service wrapper. Here it's kind of expected that you're going to be doing more work on other entities, for example, but you also won't face the same kind of re-invoke when you persist the changes to the other entities.

You use the service wrapper to override the add, update and delete methods.

In each one you do your thing, i.e. for add/update you find the 5 w/ the "new" category, find the one to remove it and use the injected original reference to save the update. You then modify the current incoming one, either on way in or if it is easier, on way out to add the "new" category.

For the delete, it's about the same except you're trying to find an older one to re-apply the "new" category to.

https://help.liferay.com/hc/en-us/articles/360029144671-Overriding-Liferay-Services-Service-Wrappers-