On one hand there is probably no other way to make this work, but on the other hand I'm afraid of that this change considering the other methods, especially the saving ones, that do not use the flush, won't work.

With the setting allow_update_outside_transaction we will only auto-commit the change (which is also not good) if we use the flush (this is probably why you've added flush: true to the create method).

I would also be aware of the InventoryItem publishPersistenceEvent - without transaction and with auto-commit (flush: true on update) we might face some weird exceptions when the afterUpdate would be executed. Have you made sure those work?

I think the best idea (and the "cleanest" one) would be just to live with the exceptions that might be thrown, create tickets and move the other methods to the service layer (or temporarily add @transactional to the "risk" methods one by one with a TODO to move this to the service....)

@kchelstowski In case I hadn't mentioned it before it would be great to explore this as part of OBGM-515. If that's too much, we should be adding color to that ticket so we can create other spike tickets to explore specific things we do not yet know about how things within Hibernate work. The @transactional annotation on controllers would be a very good topic to explore on its own.

Given how massive the InventoryService class is we should be thinking longer term about how to refactor this into smaller classes.

I think the obvious options are

• Domain (Product, Inventory, InventoryItem) which we used and caused this mess
• Functional area (transfer vs movement vs recall) which seems way better but might have some overlap that we need to contend with
• Other suggestions?