Announcement Announcement Module
Collapse
No announcement yet.
Running batch samples in Oracle 10g Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Right, so you'd better check the version of Oracle that the jars come from. If it isn't 10g (and reasonably high patch level) you probably need to upgrade.

    Comment


    • #17
      I have used the Oracle jar compatiple with 10g and its version is 10.2.

      Comment


      • #18
        Originally posted by Dave Syer View Post
        I'm sure someone else must be using Oracle, but most of the folks I know using Spring Batch in anger seem to be on DB2 for some reason.
        I have written a restartable custom batch process using spring batch (m3), and am testing it using both Derby and Oracle (9i) as databases to hold the spring batch job control tables. I get no problems with Derby, but have the following issues with Oracle which may be relevant here:

        1. I used a SimpleJobIdentifier. When accessing the BATCH_JOB table spring batch sets the value of JOB_KEY to an empty string. (Set log4j.category.org.springframework.jdbc=DEBUG to see this). On Oracle a zero length string is treated as a NULL so on restart of a FAILED job the effective predicate in SQL to locate data on BATCH_JOB becomes <... JOB_KEY = NULL ... > where JOB_KEY data is NULL. As NULLs do not equal on SQL no row is returned and the job proceeds as if it were a new run and not a recovery of a failed run. I worked round this by using ScheduledJobIdentifier and specifying a key, but probably spring batch should either place a dummy value in JOB_KEY when one is not specified (easy) or not use JOB_KEY as a predicate in SQL commands where JOB_KEY was not specified (logical, but more complex).

        2. I also found a difference in the use of DATE for column SCHEDULE_DATE. If you set up the "Job" with a date/time value in the jobId e.g.
        jobId.setScheduleDate(new Date()); then Derby ignores the time portion, but Oracle DATE columns store it and so on recovery having a different time causes the job to fail to locate the row on BATCH_JOB. If spring batch only expects to use the date portion of the the ScheduleDate, then it might be worthwhile for it to internally set the time part to zero to avoid this discrepency. Although I accept it is easy for the caller to ensure this criterion is met.

        I'm not sure if any of this helps in this thread, but perhaps it may have some bearing on it.

        Comment


        • #19
          All this is really useful information (so I created an issue: http://jira.springframework.org/browse/BATCH-281), and some new tests obviously need to be added. But does it explain why some people have reported failed unit tests? The tests all pass in my environment against Derby and 10g, so can anyone shed any light on that?

          Comment


          • #20
            How come I still have the issue when I used m4

            I am using 10.2.0.3 oracle driver but I am accessing an 9i database. And I still get junit.framework.AssertionFailedError: expected:<5> but was:<7>:

            Comment


            • #21
              I am also using the 10.2.0.3 oracle accessing 10g database, same error with m5.

              Comment


              • #22
                Can you provide some more data? It would help a lot if we could see the job meta data. Best would be if you would: start with a clean database; run only the sample test that fails; post back the contents of the step execution and execution context tables.

                Track progress here: http://jira.springframework.org/browse/BATCH-439
                Last edited by Dave Syer; Mar 8th, 2008, 02:56 AM. Reason: added JIRA link

                Comment


                • #23
                  test trace using m5

                  I also had the same problem with m5 here. Trace attached.

                  Comment

                  Working...
                  X