# Transactions without mutations **URL:** \ **Category:** Using FoundationDB\ **Created:** [May 24, 2023, 8:00pm UTC](https://forums.foundationdb.org/t/transactions-without-mutations/3977 "2023-05-24T20:00:46Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\ **Post date:** [May 25, 2023, 1:47am UTC](https://forums.foundationdb.org/t/transactions-without-mutations/3977/2 "2023-05-25T01:47:47Z")
Even if changes aren’t durable, it’d still seem safe to return before TLog commit, as even if a recovery happens and some in-flight transactions get rolled back, none of them could have conflicted with your read-only transaction otherwise the resolver would have objected in the first place. It’d be super weird, as you’d now have essentially a read version in a window of versions that was skipped by a recovery, but I can’t immediately think of anything that’d break. I think you’d basically just have to ask simulation 😕. I’m not even convinced that a read-only transaction committing successfully and everything else around it getting rolled back post-recovery would be a linearizability serializability violation. [Layer for read-write transactions lasting longer than 5 seconds - #10 by alexmiller](https://forums.foundationdb.org/t/layer-for-read-write-transactions-lasting-longer-than-5-seconds/1318/10) was a similar old discussion of ours for long-running read-write transactions, and I still similarly think that periodically re-validating the read set and bumping the read version up would work there too. You’d doubly similarly need to make sure that you re-validate your cache before 5s, otherwise you’ll have to throw the entries away or re-read and compute the cached value. re: wacky idea, you have to go through the resolver anyway, so I think you’re going to have to have already picked a sensible commit version to use anyway? You’d even have a batch index, it’s just that you could reply early. Trying to tack an extra commit read-only transaction onto an already-committed batch feels, I mean, maybe it could work? But I’m not even sure the resolver supports resolution up to some version other than the most recent? This seems like a definitely harder direction to try and go. --- _[View the full topic](https://forums.foundationdb.org/t/transactions-without-mutations/3977)._