Refactoring

[beberlei]

Refactoring to allow different propagations of requests and clean up the transaction management. Also split up responsibilities.

[schmittjoh]

Is there a way to send a 500 response without the rollback?

[beberlei]

Not yet, but you will be able to specify exceptions not to rollback for in any request.

@Tx\Transactional(noRollbackFor="SomeException")

[schmittjoh]

It would be nice to extract this logic somehow so I can re-use it in an AOP implementation.

[schmittjoh]

A few questions:

1. Assuming an exception occurs in the master request, and I want to process the exception in a listener that I define, do I need to register it with a specific priority?
2. Assuming I enable transaction management for a controller, but I return a 500 (or some other error response) from this controller. Is the transaction rolled back then? I would say no, or at least this should be configurable.
3. Can we guarantee that the transactional scope is always available during the request scope? What happens if a transaction is rolled back?

I'm not sure whether the implicit scoping is a good idea. It sure is easier to migrate to this bundle then, but in the long term I'm sceptical whether it is good to keep developers unaware of this. It might lead to some code being executed twice (like in constructors) that the developer did not intend to.

[schmittjoh]

I think this should be inEdges as you are interested in all services that have a dependency on the connection (in contrast to all dependencies that the connection has onto other services).