The danger is that you can think your code is executing in a transaction when it isn't. It may not be relevant in your case but if ever your other db starts getting updates and not just selects, you will probably not realise the problem until it has done damage...
As a principle I stay away from:
<tx:annotation-driven transaction-manager="transactionManager"/> A specific transaction manager documents the way it is used and you don't have "magic" in the background obscuring the fact that it only works for one data source.
In any case I will post two solutions to using transaction managers with multiple db's in spring:
1. With annotations:
Use these annotations with the below transaction managers...
@Transactional("db1TM")
@Transactional("db2TM")
<bean id="db1TM" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource1"/>
</bean>
<bean id="db2TM" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource2"/>
</bean>
2. With AOP:
Specify an advice with pointcuts that hit the classes that execute db queries:
<bean id="db1TransactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource1"/>
</bean>
<!-- Advice dealing with which methods should be transactional -->
<tx:advice id="db1TransactionAdvice" transaction-manager="db1TransactionManager">
<tx:attributes>
<tx:method name="*"/>
</tx:attributes>
</tx:advice>
<!-- Pointcut for crosshair service methods to be transactionally advised -->
<aop:config>
<aop:pointcut id="db1TransactionPointcut" expression="execution(* com.mysite.spring.app.IDb1MybatisService.*(..))"/>
<aop:advisor advice-ref="db1TransactionAdvice" pointcut-ref="db1TransactionPointcut"/>
</aop:config>