The M3 change only affects selects. Previously, each select was performed with autoCommit=false, and was followed by an explicit Connection.commit(). Now we switched to autoCommit=true and no explicit commit.
Hope this explains the change. Andrus > On Jul 12, 2026, at 4:10 AM, Jurgen Doll <[email protected]> wrote: > > Hi Andrus > > Wrt autoCommit I'm a bit puzzled as to why: "Cayenne no longer wraps > selecting queries ...." therefore ".... this means that for the first time > Cayenne operates with Connection 'autoCommit=true'" ? Are selects and > autoCommit related in some way ? > I'm asking because in my understanding autoCommit is only relevant to updates > and inserts which will still be wrapped as transactions won't they ? > Or are you saying that there isn't any default transaction wrapping at all > any more in Cayenne, even for inserts and updates ? > > Thanks for a great library! > Jurgen > > On Jul 11 2026, at 9:21 pm, Andrus Adamchik <[email protected]> wrote: >> As a Cayenne user, the majority of my apps in the last 25 years were >> "autoCommit=false" just because that's how the framework worked. So this is >> also new to me and based on research, not production experience. So I'd very >> much like to get community feedback on the actual behavior and potential >> pitfalls. >> >> Andrus >> >>> On Jul 11, 2026, at 4:52 AM, [email protected] wrote: >>> >>> Hello Andrus, >>> >>>> But this means that for the first time Cayenne operates with Connection >>>> "autoCommit=true". >>> >>> 😱 >>> This setting is more scary that an Halloween costume to me! 😅 >>> I trust your understanding of the trade-offs at play, but I have >>> always considered autoCommit the option used by toy projects, not >>> suitable for serious tasks. >>> >>> But my views may well be obsolete by now. 😁 >>> >>> Cheers, and –as always– huge congratulations to all people involved in >>> moving the project forward. >>> >>> Giulio Cesare >>> >>> On Tue, Jul 7, 2026 at 3:17 PM Andrus Adamchik <[email protected]> wrote: >>>> >>>> I am glad the new change didn't break much stuff :) Always a concern with >>>> all the new ideas. >>>> >>>> BTW, as you probably noticed, we are now exposing translated queries with >>>> parameters as standalone record objects instead of going straight from >>>> translator to PreparedStatement, so they can be captured, inspected, >>>> logged, etc (e.g., what the SQLLogger does). >>>> >>>> And on the broader topic of observability, we started an effort to >>>> integrate OpenTelemetry into Bootique, and I hope this will come back to >>>> Cayenne as well. Would be nice to have otel spans for queries. But as your >>>> video demonstrates, explicit instrumentation is almost irrelevant these >>>> days. The tools are so good... they can grab the logs, or do automated >>>> runtime instrumentation and show you transaction traces with next to zero >>>> effort. >>>> >>>> Andrus >>>> >>>> >>>> >>>>> On Jul 6, 2026, at 7:15 PM, Hugi Thordarson <[email protected]> wrote: >>>>> >>>>> Hi Andrus, >>>>> >>>>> first — that logging is a vast, vast improvement, I'm loving it! >>>>> >>>>> So happens I've been playing a lot with Cayenne's logging lately. Very >>>>> happy about how easy it was/is to hook into query logging and I've used >>>>> it to profile SQL-queries in my web application templates for years now — >>>>> keeping track of the time methods spend querying to find performance >>>>> problems (profiling/aggregating by bindings rather than methods really, >>>>> in WO terms) and watching the SQL they executed. >>>>> >>>>> Helpful, but has always been private utility logic for myself since it >>>>> just prints ugly text reports and I never took the time to make it pretty >>>>> and usable for others. >>>>> >>>>> But that was before Claude :). So now there's this: Inline SQL logging. >>>>> Probably easiest described through video — >>>>> https://www.youtube.com/watch?v=hoW1WusKSRo . >>>>> >>>>> …works great with the new SQLLogger interface. Already ported, since I'll >>>>> be switching to -SNAPSHOT (in dev only for a while, to test the behaviour >>>>> of the new transaction setup, really looking forward to putting it >>>>> through it's paces). >>>>> Been using M2 in production since release and it works great, congrats on >>>>> another awesome release :). >>>>> >>>>> Cheers, >>>>> - hugi >>>>> >>>>> >>>>> >>>>>> On 6 Jul 2026, at 13:37, 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >> >
