Page Comparison

...

SBOI lock = "/SBOI/" + runnable.getComponentName();

example: /SBOI/SampleComponent

batch lock = "/"+runnable.getComponentName() + "/B" + batch.getBatchID() + "-RT" + batch.getRoundTripNumber();

Autonomous component locking procedure 1

Each of the autonomous components will exist as cron jobs. Periodically, often every minute or thereabouts, the cron job will activate. It will then follow the procedure below.

1. Lock "SBOI+component name"
   1. query SBOI for batches
   2. For each returned batch
   3. Attempt to lock the "batch+component name"
   4. if successful, break loop
2. unlock "SBOI+component name"
3. Do work on locked batch (if any)
4. store results in DOMS
5. unlock "batch+component name"

...

example: /SampleComponent/B400022028241-RT1

Why?

An autonomous components will be able to "poll" the Newspaper Batch Event Framework for events that have happened. The component will know which events should have occurred for a batch before I can start processing the batch. Also which events should have occurred and failed, and which events should not have occurred. The component also needs to know which batches it is currently working on itself. This is what the zookeeper tracks the locks for.

Autonomous component locking procedure 

Each of the autonomous components will exist as cron jobs. Periodically, often every minute or thereabouts, the cron job will activate. It will then follow the procedure below. Each autonomous component will have a field called "simultaneousProcesses", which indicate how many children it can spawn.

1. Lock "SBOI+component name"
2. query SBOI for batches
3. For each returned batch
   1. Attempt to lock the "batch+component name"
   2. Do work on locked batch (if any). Possibly spawn sub process
   3. store results in DOMS
   4. unlock "batchCreate child until number of children == "simultaneousProcesses"
4. unlock "SBOI+component name"unlock "SBOI
5. Start each child
6. Wait for all children to complete their work
7. unlock "batch+component name"

Which one will we use?

Method 1 is simpler to implement (and already done). Method 1 will only maintain a very shortlived lock on SBOI. To run method 1 on three batches, just start it three times.

Method 2 is conceptually simpler to understand. It allows for developer controlled degree of parallelism, but will also force us to code this ourselves. 

 Each child will do the work described and store the result back into DOMS.

The autonomous component will, as described above, NOT finish before all spawned children have finished. It is the responsibility of the cron system to not start the autonomous component before the previous invocation have finished