--------------Original Comment History----------------------------
Comment from = ScottKurz on 2016-01-11 16:07:06 +0000
The spec says (in the StepContext#getPersistentUserData() Javadoc at least), that persistent user data is persisted as part of a checkpoint and when the step ends.
It might be nice for a batchlet though to be able to trigger a save/persist of the persistent user data using an API call ( would save the developer from having to invent his own solution).
It seems like the complete phrasing would have to take into account the fact that there might or might not be a transaction active (for the batchlet, it would not be one started by the batch container). E.g. when persistence is supplied by a transactional database, and we get the "flush" or "persist" call, do we write to the DB as part of the current tran ( letting the app decide whether to commit or rollback)? Or do we want/need to provide the ability to suspend an active global tran and immediately commit the DB update. The immediately commit option could even be useful in a chunk step.
Seems like we need to at least consider all these cases.
Comment from = ScottKurz on 2016-02-07 16:24:15 +0000
Another use case potentially would be for partitions, for the mapper and the reducer's beginPartitionedStep(). Since there's no chunk on the top-level thread, this isn't guaranteed to persist until the step ends, which is of no use if the JVM blows up.
Originally opened as bug 7474 by ScottKurz
--------------Original Comment History---------------------------- Comment from = ScottKurz on 2016-01-11 16:07:06 +0000
The spec says (in the StepContext#getPersistentUserData() Javadoc at least), that persistent user data is persisted as part of a checkpoint and when the step ends.
It might be nice for a batchlet though to be able to trigger a save/persist of the persistent user data using an API call ( would save the developer from having to invent his own solution).
It seems like the complete phrasing would have to take into account the fact that there might or might not be a transaction active (for the batchlet, it would not be one started by the batch container). E.g. when persistence is supplied by a transactional database, and we get the "flush" or "persist" call, do we write to the DB as part of the current tran ( letting the app decide whether to commit or rollback)? Or do we want/need to provide the ability to suspend an active global tran and immediately commit the DB update. The immediately commit option could even be useful in a chunk step.
Seems like we need to at least consider all these cases.
Comment from = ScottKurz on 2016-02-07 16:24:15 +0000
Another use case potentially would be for partitions, for the mapper and the reducer's beginPartitionedStep(). Since there's no chunk on the top-level thread, this isn't guaranteed to persist until the step ends, which is of no use if the JVM blows up.