can it support a database with no transactions?

[kdelong]

I'm getting confused. It seems to me that there are more than one transaction managers involved.

First, there's the one for the batch database where the metadata (JobExecutions etc) are stored. I have a datasource, transaction manager, and the recommended AOP TXN configs (direct from the user manual), configured with

	
<aop:config>
	    <aop:advisor 
	    	pointcut="execution(* org.springframework.batch.core..*Repository+.*(..))"
	    	advice-ref="txAdvice" />
	</aop:config>
	
	<tx:advice id="txAdvice" transaction-manager="transactionManager">
	    <tx:attributes>
	        <tx:method name="create*" propagation="REQUIRES_NEW" isolation="SERIALIZABLE" />
	        <tx:method name="*" />
	    </tx:attributes>
	</tx:advice>

However, the transaction manager I'm asking about is the one configured in SimpleStepFactoryBean. When my Step is an ItemReader reading a file, should I use the same TransactionManager that points to the batch database?

	<bean id="myJob" class="org.springframework.batch.core.job.SimpleJob">
		<property name="jobRepository" ref="jobRepository" />
		<property name="steps">
			<list>
				<bean id="myStep" class="org.springframework.batch.core.step.item.SimpleStepFactoryBean">
					<property name="jobRepository" ref="jobRepository" />
					<property name="transactionManager" ref="?????????????????????"/>
					<property name="itemReader" class="FlatFileItemReader"/>
					blah blah

I guess you are suggesting that I use my batch database transaction manager in place of the ????? above. That's fine, I can do that. However, it seems that if I used ResourcelessTransactionManager, it doesn't affect the transactions on the batch db; those are set by the AOP and TX config above.

Do I have that correct? I'm very sensitive about transaction configuration and want to make sure I get it right.

OTOH, if my step used a database item reader, then I'd configure a transaction manager for that particular database (or JTA) for the SimpleStepFactoryBean. Correct?

Sorry for the confusion.

[dkaminsky]

That's pretty much what I was saying

There's no reason you can't use the same tx manager for both your metadata database and your business transactions. Hook the resourceless transaction manager into both and see if that solves your issue.

[Dave Syer]

I think Doug was responding to the original post, not the last one, so let me clarify. The transaction manager injected into the step should always be the same as the one that is used to wrap the repository declaratively. Sorry for the confusion, but it is quite important for restartability that we can piggyback on the business transaction in the step - we only need to store position data for your open files, for instance, if the current chunk is successful.

[dkaminsky]

I apologize for my confusing response - I most likely was responding to the wrong point in the thread - that's what I get for trolling the forums at that hour.

To be clear, you are 100% CORRECT that there can be up to two transaction managers involved - one for the AOP advice around the batch metadata repository, and one that is injected into the steps. However, these generally should be the same.

I'm confused as to whether or not you have tried using a transaction manager and encountered failures, or are just anticipating failure because Informix doesn't support transactions.

I believed (and I could be wrong) that the Spring Transaction module would properly handle this and not attempt to dispatch a transaction commit command if it was not supported by the underlying datasource.

[kdelong]

The transaction manager injected into the step should always be the same as the one that is used to wrap the repository declaratively.

Cool, that makes clear the file-to-file situation. I'll fix up my txn config. Thanks!

Now let me change the setup a bit; suppose the Step writes into a different database (call it "content"). Our batch jobs access a bunch of different databases. We have not installed the spring batch schema in all of them; instead, we have a central "batch" db to hold the repository.

Dave, in this case I would still inject the batch repository tx mgr into the step factory, and wrap my DAO to the content database that the step writes to with declarative txn for that db. Is that correct? Or should I use JTA if my batch repository schema is in a different db than the step writes the items to?

[Dave Syer]

JTA is the only bullet proof option. Some people rely on single-phase commit of multiple datasources, risking unrecoverable failure in between commits of two connections from different data sources. Spring doesn't (yet) support that out of the box though - you have to write your own PlatformTransactionManager, or use two DataSourceTrabsactionManagers and use TransactionSynchronizations to link up the commits.

[kdelong]

Looking in a little deeper, there's one thing that still puzzles me. The user guide suggests this configuration

	<aop:config>
	    <aop:advisor 
	    	pointcut="execution(* org.springframework.batch.core..*Repository+.*(..))"
	    	advice-ref="txAdvice" />
	</aop:config>
	
	<tx:advice id="txAdvice" transaction-manager="transactionManager">
	    <tx:attributes>
	        <tx:method name="create*" propagation="REQUIRES_NEW" isolation="SERIALIZABLE" />
	        <tx:method name="*" />
	    </tx:attributes>
	</tx:advice>

By putting REQUIRES_NEW on the repository DAOs, then we in fact are running in a different transaction than the original (which is suspended). This new repository transaction will commit independently of whether the step's transaction committed.

So I wonder if that's a typo, and it should be REQUIRES, or whether I should just inject the ItemWriter's database's local tx manager and bag JTA (I hope :-)

[Dave Syer]

That method is never called inside another transaction started by Spring Batch. It is there to force the transaction manager to adopt the correct attributes if the user mistakenly has wrapped the call to Job.execute() in a transaction.

[kdelong]

got it! Thanks so much!