As Claude would say, you are absolutely right to question this :) With the disclaimer that we are dealing with a bunch of independent databases and a myriad driver settings so YMMV, reads should be atomic in auto-commit mode and the results consistent for whatever moment in time.
Default transaction isolation level (i.e. whether you see uncommitted data from other transactions; something Cayenne does not touch) is still in effect. A good example for our mental experiment is disjoint prefetches (i.e. multiple queries previously ran in a single tx). In theory, nothing has changed for them under READ UNCOMMITTED and READ COMMITTED levels. But higher levels of isolation will behave differently after this change. Also, we may need to explicitly handle edge cases (such as statement "fetchSize" that may require a tx). Andrus > On Jul 6, 2026, at 6:27 PM, Michael Gentry <[email protected]> wrote: > > Could there be an issue where you read in bad data because you are no > longer in a transaction? For example, if some other connection > updated/deleted data while your transactionless SELECT was running? > > On Mon, Jul 6, 2026 at 9:37 AM Andrus Adamchik <[email protected]> wrote: > >> Hi, >> >> I wanted to highlight a few things in the upcoming M3. They are already on >> master, so maybe some brave souls can take it for a spin and give us >> feedback :) >> >> 1. Cayenne no longer wraps selecting queries (or at least those it can >> reliably identify as selecting) into transactions. >> >> I had a suspicion for years that we shouldn't be doing that. Now I was >> able to vibecode real benchmarks on multiple databases, and time savings in >> the JDBC layer with faster queries are about 2x! (as each useless "commit" >> is a separate command sent to DB that needs to be processed). But this >> means that for the first time Cayenne operates with Connection >> "autoCommit=true". So I'd appreciate feedback if this causes any weirdness >> with your DataSources. >> >> >> 2. SQL logging changes. There are multiple changes. Some address >> operational concerns (saving hundreds of GB of storage space; single-line >> logs are easier to parse), others are "quality of life": >> >> * No tx for selects (mentioned above) by itself cuts down on 2 log lines >> per query >> * The new logger name is short and descriptive "cayenne-sql" >> * ERROR log level for queries that result in exceptions >> * SQL query logs are single-line. Parameters, timers, result counters, >> generated keys are placed on one line and rendered in a compact format. Tx >> wrapping is still done on separate lines (as a tx can include more than one >> SQL statement) >> >> INFO cayenne-sql tx started >> INFO cayenne-sql INSERT INTO BINARY_PK_TEST1(BIN_ID, NAME) VALUES(?, ?) | >> bind:[BIN_ID:FBBC4034ED8F0214B2C559CF1029C1868A66F0D59208A36C9365126C248C...,NAME:'master1'] >> updated:1 time_ms:0 >> INFO cayenne-sql tx committed >> >> * Mnemonic table aliases. No more meaningless t0, t1, t2: >> >> INFO cayenne-sql SELECT p.ESTIMATED_PRICE, p.PAINTING_DESCRIPTION, >> p.PAINTING_TITLE, p.ARTIST_ID, p.GALLERY_ID, p.PAINTING_ID, g.GALLERY_ID, >> g.GALLERY_NAME FROM PAINTING p LEFT JOIN GALLERY g ON p.GALLERY_ID = >> g.GALLERY_ID | selected:1 time_ms:0 >> >> * No alias for single-table queries >> >> INFO cayenne-sql - SELECT ESTIMATED_PRICE, PAINTING_DESCRIPTION, >> PAINTING_TITLE, ARTIST_ID, GALLERY_ID, PAINTING_ID FROM PAINTING | >> selected:2 time_ms:0 >> >> >> (I am also thinking of lowercasing the SQL so that logs don't look like >> they are screaming at you :)) >> >> Andrus >> >> >> >> >>
