Announcement Announcement Module
No announcement yet.
Spring Batch or How Not to Design an API Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Batch or How Not to Design an API

    Hi Spring Batch commiters,

    I do think you guys should read this:

    I think some users are thinking the same about this post, including me.
    You could find good ideias to improve the framework for the next major version.

    Best Regards,

  • #2
    With all due deference to the Spring Batch guys, most of the blog author's issues with the framework are poppycock.

    Most people need the work of a batch job to be transactional. I surely do. I don't overwrite records, I add new ones and I don't want them to be written multiple times by failed jobs that have restarted.

    Many people need a batch job to be restartable (so if it fails, the error can be corrected, if possible, and the batch job will pick up where it left off). I need this feature, and I'm sure I'm not alone.

    WRT to the CSV parser complaints, I too had some issues with the parser's strictness but I had two obvious options: use it as is or write my own. The first option was the easiest as I had business code to write--I didn't want to waste time writing another parser.

    The bottom line is that the Spring Batch folks have put together a nice framework that provides a good foundation for batch processing tasks. Batch processing requirements are typically very specific so while they put together a reasonable number of default implementations for common operations, they can't anticipate and accommodate EVERY scenario.

    Frankly, I'm very pleased with what they've provided. It has saved me quite a bit of work in implementing some web initiated batch processes.


    • #3

      I`ve been using Spring Batch since the first milestones and I also do think it`s a wonderful framework.

      However, we always have space to improve. Nobody is saying we don`t need transacional jobs or restartable jobs. WE DO NEED THEM. But, we don`t have any reason to complicate things for those tham don`t need in a particular case.

      The framework should be more friendly with this stuff. If I don`t want a JobRepository, so be it. If i don`t need restartable jobs, so be it. Understand?



      • #4
        I did read the blog, and suggested to the author that he bring his issues here or to JIRA. My impression: all of them are well reasoned, but some have trivial workarounds, and even the most serious challenges are not flaws in the API, but design decisions taken about the implementation. One issue was actually of Spring prototype creation, so nothing to do with Batch as such. Anyway, we do take constructive criticism - I'd hope we were well known for it - and always ready to listen to new ideas. If there are improvements that a lot of people feel strongly about we have no choice but to make them. There might be some debate, and we might not agree with everything that everyone asks us to do, but we would always have a good reason and try to be accommodating. Of course we can't change the APIs in a point release, but we can change or add implementations.


        • #5
          Maybe i am missing something in my code but i have no issue running multiple jobs at the same time.

          I am using the SimpleJobOperator instead .... not sure.

          As far as the transactionManager complaint .... that is a bit silly i think any prodcution app will go against the DB.

          The not being allowed to restart successful jobs i can understnad but i think its just a matter of what a job is. It would be confusing to change it other ways.

          *MY* only real complain with spring batch which i thought about blogging once and with the traffic he is getting maybe i should is the LACK Of mutli threaded support out of the box.

          Sure it can be done, we do it. But just about all the readers and writers out of the box lack the support. Thats what i think personally sucks. I mean dont get me wrong i understand why creating synchronized methods etc requires overhead and if one didnt want that then its a waste. I guess i am udner the idea that if you are doing batch why WOULDNT you want multi threaded support?