Integrate with DB and other external systems
* sensible default DB commit-frequency. Batch jobs need a different commit frequency than interactive applications. P505 [[ mysql stored procedures ]] Without this feature, a novice batch user would commit on every update. Commit frequency can be configurable.
* [x] Expect capabilities — integrate with interactive systems
* [x] ability to restart a remote server
* integration with stored procedures and triggers
* integration with ftp, auto-reconnect
* [x] integration with servlets etc, with support for cookies[x]. batch^interactive? A batch can flood and overwhelm a URL.
* avoid db contention due to concurrent updates to the same “page” ie data block. Spread updates over separate data blocks for parallel updates.
* resilient to network outage. Batch vs interactive?
* integration with MQ, usually as a sender
— infrastructure support
* adjustable load level on external partner systems. Batch jobs can generate higher load than normal on unprepared “trading-partners”. Persistent XML configuration. Ideally, load level is adjustable in real time.
* detect peak hours for a database/URL and back off. For a mission-critical DB, our friend’s website, a shared scarce resource, or a resource-tight website, our batch may need extra intelligence to detect changes to peak hours, instead of a hard-coded schedule. It takes Just a single outbreak of flooding (due to change in peak-hour schedule) to bring down a site, damange trust, spoil our image, or even generate bad publicity