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 >>>> >>>> >>>> >>>> >>> >>
