Using "autoCommit=false", the DB would implicitly BEGIN a tx on select. So without a commit it will leave an idle transaction behind with some resources allocated for it on the DB side. While your connection pool may (or may not) rollback the tx when a connection is returned, but in general, connection user is responsible to call either commit or rollback if "autoCommit=false" is in effect.
Andrus > On Jul 17, 2026, at 2:14 PM, [email protected] wrote: > > Hello Andrus, > > more of a curiosity here than an actual Cayenne consideration: I love > the idea of non performing an explicit commit for select queries, but > do you actually need the set 'autoCommit=true', or is this just a safe > option in case there were triggers or other subtle changes on the data > that would not be saved otherwise? > > Thanks, > > Giulio Cesare > > On Sun, Jul 12, 2026 at 10:35 PM Andrus Adamchik <[email protected]> wrote: >> >> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >>
