Page History

...

    <aop:config>
        <aop:advisor pointcut="execution(* *..StudentService.*(..))" advice-ref="txAdvice" />
        <aop:advisor pointcut="execution(* *..InstructorRoleAuthorizationService.*(..))" advice-ref="txAdvice" />
        <aop:advisor pointcut="execution(* *..StudentRoleAuthorizationService.*(..))" advice-ref="txAdvice" />
        <aop:advisor pointcut="execution(* *..StvRolesAuthorizationService.*(..))" advice-ref="txAdvice" />
        <aop:advisor pointcut="execution(* *..ApplicationVariableService.*(..))" advice-ref="txAdvice" />
    </aop:config>

    <tx:advice id="txAdvice" transaction-manager="transactionManager" >
        <tx:attributes>
            <tx:method name="save*" propagation="REQUIRED" rollback-for="*" />
            <tx:method name="delete*" propagation="REQUIRED" rollback-for="*" />
            <tx:method name="*" propagation="SUPPORTSREQUIRED" read-only="true" />
        </tx:attributes>
    </tx:advice>

The first part - <aop-config> - defines which parts of the code (join points) should participate in the transactions, using AspectJ-style pointcut expressions. For example,  "execution(* ..StudentService.(..))" means that for every execution of a method in the StudentService class, the behavior specified by "txAdvice" should come into play.

The second part,  <tx:advice... specifies the transaction "advice" or behavior that should be applied to the join points associated with the advice, and also associates the transaction manager (specified elsewhere) with the advice. The example allows a finer-grained definition of methods and their transaction characteristics (e.g. all methods with names starting with "save" and "delete" will require a transaction and will roll back if any exception is encountered). The third <tx:method> specifier in the example is the default - methods not matching the explicit method name patterns will get this default transaction behavior.

For the most part, the The default propagation behavior is specified as "REQUIRED", which means that if there is a transaction in progress, the code will participate in that transaction, but it there is no transaction in progress, a new transaction will be created. Only in unusual circumstances would we want to specify different propagation behavior.

If an unchecked exception (e.g. NullPointerException) is thrown during execution of code participating in a transaction, any uncommitted database updates will be rolled back. If no exceptions are thrown, or a checked exception (e.g. Exception) is thrown, the transaction will end with a commit.

...