Exception if transaction timeout occured before partitions complete about jsr352

[fantarama]

JSR define this workflow! So my question is how can I handle long time partition execution if analyzer work in a unique transaction? I excpected that was the single method in transaction not the loop.

6 begin transaction // thread A
7 // Actions 9-12 run continuously until all partitions end.
8 // when collector payload arrives:
9 <->PartitionAnalyzer.analyzeCollectorData // thread A
10 // when partition ends:
11 <->PartitionAnalyzer.analyzeStatus // thread A
12. // Remaining actions run after all partitions end:
13. // if rollback condition occurs:
14. <->[PartitionReducer.rollbackPartitionedStep] // thread A
15.
16. // else not rollback
17. <->[PartitionReducer.beforePartitionedStepCompletion] // thread A
18. commit transaction // thread A

[chengfang]

will look into it next.

[chengfang]

According to the spec section you quoted above (section 11.7), all the work on the main thread by analyzer and reducer are in one single transaction. So I think you will need to adjust tx timeout to allow for time taken by analyzer and reducer processing, partition scheduling and dispatching and communication overhead. The scope of the partition main thread transaction (single-method vs loop), I will check with spec expert group to see why it is designed this way.
https://java.net/projects/jbatch/lists/public/archive/2014-08/message/1

[chengfang]

See RI Bug https://java.net/bugzilla/show_bug.cgi?id=6356
PartitionAnalyzer transaction boundary on partitioned chunk (and batchlet) step need clarification

[fantarama]

Yes they admit taht spec need a clarification. By now to solve my problem i've made a fix to jberet and I've updated my Wildfly 8.1 server installation.

[chengfang]

Somewhat related issue:
JBERET-117 Arjuna transaction timeout with partitioned step (there is no partition analyzer or collector)