just to be sure - do you know there's already a JPA store implementation? See https://github.com/infinispan/infinispan/tree/master/persistence/jpa
Regarding TXs: The JPA store write occurs in the second phase of Infinispan TX transaction commit. There's really no space for failures - when the DB transaction fails, you can try again or leave the DB out-of-sync with Infinispan and throw an exception (however, this would not rollback the other writes in the Infinispan TX).
The way how JPA store is designed adheres to expected use case - cache or in-memory data grid with transactions involving few keys (say, tens at most), not flushing entire cache into JPA. You're absolutely right that the performance is not optimal even for this UC as for more writes there's the latency round-trip. I am not 100% sure but async store could deal with this, executing the stores in parallel - however, the level of concurrency would be limited, we still cannot speak about any batching.
I don't think that huge transactions involving updates of millions of entries are something that could be recommended. The whole transaction is sometimes transmitted over network as single message, therefore, it has to be buffered.
However, some decent batching could be handy. You can add a feature request for AdvancedCacheWriter.update(Set<MarshalledEntry<? extends K, ? extends V> entries)