This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Business Transactions not rolled back

Apr 17th, 2008, 08:40 AM

Hello All,

I believe I should provide transaction configurations for my DAO in order for it to rollback if the process failed in the middle. Here is my question:

I started with a job to read from a file and write it to a database. I set the commitInterval to be 5000. There were about 60,000 records in that file and I purposefully stopped the process in the middle when the commitCount in my BATCH_STEP_EXECUTION was 6 and item_Count was 30,000.

In theory when I look at this number, I would assume that 30,000 records were read and saved to the database. But in my table I could find little more than 30,000 records.

I am assuming it is just because I didnt declare any transaction for my business DAO, it didnt rollback those extra records. If my job is restartable, what would happen in this case, the job will start reading from 30,001th record? I hope yes, but in that case, it may throw data integrity violation rite??

Doesn't sound right. What transaction manager are you injecting into your step? Is it the same one that is used in the JobRepository tx:advice (as per user manual)? Is it connected to the same database as your business dao?

Comment

I didnt do anything special, while I was just using tradeJob sample, only difference was I extracted out onlyt those files that were required to run tradeJob sample (including simple-job-launcher.xml), I didnt make any configuration change (except fileLocator, and the DAO to insert into my own table).

Comment

I believe I should provide transaction configurations for my DAO in order for it to rollback if the process failed in the middle. Here is my question:

You really shouldn't have to, the transaction should be started by the framework itself, and as long as your business logic isn't calling the DAO in a new thread, you should be fine.

I started with a job to read from a file and write it to a database. I set the commitInterval to be 5000. There were about 60,000 records in that file and I purposefully stopped the process in the middle when the commitCount in my BATCH_STEP_EXECUTION was 6 and item_Count was 30,000.

In theory when I look at this number, I would assume that 30,000 records were read and saved to the database. But in my table I could find little more than 30,000 records.

How exactly did you stop it? If you just kill the process there isn't going to be a rollback. The connection should just be closed without being committed. Assuming nothing else is calling commit on the connection, and you haven't somehow set autocommit to true, it should throw them away.

I am assuming it is just because I didnt declare any transaction for my business DAO, it didnt rollback those extra records. If my job is restartable, what would happen in this case, the job will start reading from 30,001th record? I hope yes, but in that case, it may throw data integrity violation rite??

Anyone came across such scenario?

Thanks!

If you just stopped the job after the 6th 'chunk' then it should started reading after the value stored in the ExecutionContext. What is this value in your database?

Comment

I am not starting a new transaction in my DAO or not running the DAO in a new thread.

But your point makes sense about how I stopped it, I killed my JUnit test process in eclipse and I believe my db, MySql, has autocommit to true. I am going to try in another db (as I do not have admin control over MySql), which has autocommit to false then I will see what happens.

Can you send me or post any ppt, videos of your presentation? I did watch your Spring One 2007 video (last year's) but lot has changed in Spring Batch after that. Any updated material would be really GREAT for the people in this forum.