default PROPAGATION setting for non-intercepted method.

[wil-05]

The question: "if a method isn't intercepted for running in a transaction, but the calling method is running in one, what is the behaviour of the non-intercepted method ?".

* Consider a service 'someService' with 2 methods "methodA()" and "methodB()".
* methodB() is called within the scope of methodA();

 ...
methodA() {
      methodB();
}
...

* methodA needs a transactional security, so i provide one thru this: ...

<bean id="someService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
        <property name="transactionManager">
            <ref bean="myTransactionManager"/>
        </property>
        <property name="target">
            <ref local="actualTicketServiceBean"/>
        </property>
        <property name="transactionAttributes">
            <props>
                <prop key="methodA">PROPAGATION_REQUIRED</prop>
            </props>
        </property>
    </bean>

* Notice that "methodB()" isn't mentioned in the "transactionAttributes".
* The question(s): if a method isn't intercepted for running in a transaction, but the calling method is running in one, what is the behaviour of methodB:
1) is it running in a transaction ?
2) is it running the same transaction as methodA ?
3) of not (another) what is it's propagation-level (is there a default) ?

TIA
-wil-

P.S. can you point me to some resources (urls e.a.) regarding this matter. (so, something that goes beyond "NotSupported" is ..., RequiredNew is ..., but rather more in-depth. TIA again).

[robh]

The behavior of methodB() in this case is that it has access to the transactional context and any code (such as JdbcTemplate) that is aware of this context will run within the transaction.

Rob

[wil-05]

is methodB running in a transactional context (which has been propagated by methodA) ? In that case, i guess, it is equivalent with putting methodB as REQUIRED in the transactionAttributes ?!
It is not that clear to me, e.g. consider this ...
if methodB updates some data in in database and methodA throws an UncheckedException causing methodA to rollback ... will the changes made by methodB be rolled back (or were the changed persisted immediately at the moment) ?

[Andreas Senft]

is methodB running in a transactional context (which has been propagated by methodA) ? In that case, i guess, it is equivalent with putting methodB as REQUIRED in the transactionAttributes ?!

I would rather say, it's equivalent to SUPPORTED.

It is not that clear to me, e.g. consider this ...
if methodB updates some data in in database and methodA throws an UncheckedException causing methodA to rollback ... will the changes made by methodB be rolled back (or were the changed persisted immediately at the moment) ?

The changes will be persisted when the transaction is being committed.
Consider this scenario:
- methodA (transactional) calls methodB
- methodB makes changes in the database and returns
- methodA throws an unchecked exception causing the transaction to rollback.

So the changes will not be persisted, irrespective of the fact that methodB has caused them. The transaction begins before the invocation of methodA and ends after the invocation of methodA.

Note however, that you are able to configure Spring in a way to not perform a rollback on specific unchecked exceptions. See the reference documentation for details on this.

Regards,
Andreas

[wil-05]

Hello, thx,

is methodB running in a transactional context (which has been propagated by methodA) ? In that case, i guess, it is equivalent with putting methodB as REQUIRED in the transactionAttributes ?!

I would rather say, it's equivalent to SUPPORTED.

Yes, you're right, it must be "SUPPORTS", but is it "equivalent" or "is" it ? (sorry for my persistence )

It is not that clear to me, e.g. consider this ...
if methodB updates some data in in database and methodA throws an UncheckedException causing methodA to rollback ... will the changes made by methodB be rolled back (or were the changed persisted immediately at the moment) ?

The changes will be persisted when the transaction is being committed.
Consider this scenario:
- methodA (transactional) calls methodB
- methodB makes changes in the database and returns
- methodA throws an unchecked exception causing the transaction to rollback.

So the changes will not be persisted, irrespective of the fact that methodB has caused them. The transaction begins before the invocation of methodA and ends after the invocation of methodA.

Note however, that you are able to configure Spring in a way to not perform a rollback on specific unchecked exceptions. See the reference documentation for details on this.

Regards,
Andreas

[Andreas Senft]

Yes, you're right, it must be "SUPPORTS", but is it "equivalent" or "is" it ? (sorry for my persistence )

I think this question is a little bit philosophical :wink:
I would say, it behaves like it is declared as SUPPORTS, but it is not declared that way. Therefore I prefer to call it equivalent.

If SUPPORTS is somewhere defined to be the default in absence of a specifier, then you can truly say it "is". Actually I don't know if this is the case.

Regards,
Andreas