Announcement Announcement Module
Collapse
No announcement yet.
Oracle Coherence + Spring Batch Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Oracle Coherence + Spring Batch

    How to Integrate Oracle Coherence with Spring Batch? Idea is to use Oracle Coherence as sratch pad memory to be accessed by the steps. Also why is JobParameters immutable?

    Can above is achieved my extending the JobParemeters?

  • #2
    JobParameters is immutable because it's purpose is to uniquely identify an instance of a job, and nothing more. It really shouldn't be used as a place for 'scratch pad memory'. To be honest, I can't see much use for this at all short of caching some reference data that's used throughout a job run, and even in this scenario coherence would be crazy overkill. We have been looking at compute grids to help out, and there have been been some forum users that have implemented it, but I just can't see how something like coherence would add a lot of value in a batch scenario.

    Comment


    • #3
      I agree with you totally that usage of Coherence will be “crazy overkill”. So let me tell you our business use case so that you can suggest or give us some hints. We are making the claim processing system, where business rules are captured and stored in the database and as part of claim processing history claim lines (for a particular claim are retrieved) and rules are evaluated against them.

      Sample rules are shown below, which are stored in the database

      1. A supplementary product only covers a crown. The insured people themselves should pay the first 100 euro. When a crown costs more: the coverage is 75% of the amount up to 500 euro per calendar year
      2. Bleaching teeth are covered by a supplementary product also up to 500 per calendar year
      3. The combination of crown and bleaching will be covered by a supplementary product to a maximum amount of 800 per calendar year. Rule 1 and 2 should be calculated first.
      Note: - these rules can max grow to 20 MB
      The above rules is the part of the setup (done at the time of setting up of the claim processing) and there changes are not very frequent, so we think, these rules are potential candidate to be put in the cache.
      For the various claim-processing steps above rules are hit again & again. The idea is not reload these rules again and again, but put them in the cache.

      My Question: - Which is the best place to put such Meta data (rules) to avoid loading, as these rules will be called from the claim processing steps.

      Comment

      Working...
      X