The current implementation of transaction recovery depends on the fact the all pods access one shared file system storage (one PV, persistent volume). Either this is done by having split-# directories and using flock function or by approach introduced by CLOUD-2261 where OpenShift API is queried. The base idea is the same where we have several application pods (running JBoss EAP) and one singleton migration pod which manages to finish in-doubt transactions. All those pods needs to have access to shared PV.

Here the issue is that on some environments (e.g. OpenShift Online in particular) we are not provided with such PV (can't claiming the shared persistent volume). The point of this issue is to investigate and provide solution where the shared persistent volume is not necessary.

In current state we consider following options

• using jdbc object store with shared database while recovery markers (needed by algorithm introduced by CLOUD-2261) are saved through OpenShift API calls on the etcd
• using jdbc object store with shared database while recovery markers are saved in the database
• use of the stateful set (e.g. Fuse uses this approach). Here seems to be some limitations in current OpenShift (v3.9) for being able to utilized it. But it needs to be investigated.