public @interface Transactional

Runs this method – or every public method of this class – in a database transaction.

The build rewrites the compiled method: its body moves into a private method of its own, and the method keeps its name and wraps that body in a begin and a commit, with a rollback on failure. Everything is decided at build time – the propagation, the rules below, the exception types – and written in as constants and instanceof tests, so there is nothing to interpret on the call.

Because the method itself is rewritten rather than wrapped by a proxy, the transaction applies however it is called: from another bean, from this, from a private caller, or on an object the application built with new. That is the one place this differs from Spring, where a call through this silently skips the transaction.

Rollback follows Spring’s rule: an unchecked exception or an Error rolls back, a checked exception commits, and rollbackFor and noRollbackFor adjust that. When several listed types match the thrown one, the most specific wins.

Everything done through the server’s DataSource – its own methods, an entity manager’s daos, the transaction’s com.codename1.orm.session.Session – joins the transaction on the calling thread. A connection is borrowed only when the transaction first needs one.