In our app we make heavy use of transactions which we know are read-only. The JavaDocs advise using commit even on read-only transactions to make sure they don’t get GC’ed too early, since that would cancel in-progress reads.
Would it be reasonable or even beneficial to call cancel instead of commit once we’re done with the transaction?
I’m not as familiar as perhaps I should be on all of the details regarding garbage collection of outstanding reads when there are outstanding reads. I think the more general advice would be to avoid calling commit() (or cancel()) until all reads you care about have completed. The advice in the Javadoc comment also seems to predict a world where we rely on the JVM garbage collector to free up native resources, which was once the case (using a finalizer–gasp!) but now the advice is for callers to manually call close() on their transactions. If you have any reads that have not completed and you call close() on the transaction, then those outstanding reads will generally not succeed. But they also shouldn’t be cleaned up until close() is called.
One most notable thing I will add about commit() call on a read-only transaction is that it is executed entirely locally. If the transaction determines that it is read-only (that is, it has no mutations or write conflict ranges), then the commit() call will return “success” immediately without having to make a network call, so the cost of calling commit() is fairly low.