Re: M3 feature preview

As Claude would say, you are absolutely right to question this :)=20

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.=20

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.=20

Also, we may need to explicitly handle edge cases (such as statement =
"fetchSize" that may require a tx).=20

Andrus=20

> On Jul 6, 2026, at 6:27=E2=80=AFPM, Michael Gentry =
<[email protected]> wrote:
>=20
> 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?
>=20
> On Mon, Jul 6, 2026 at 9:37=E2=80=AFAM Andrus Adamchik =
<[email protected]> wrote:
>=20
>> Hi,
>>=20
>> 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 :)
>>=20
>> 1. Cayenne no longer wraps selecting queries (or at least those it =
can
>> reliably identify as selecting) into transactions.
>>=20
>> 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=3Dtrue". So I'd appreciate feedback if this causes any =
weirdness
>> with your DataSources.
>>=20
>>=20
>> 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":
>>=20
>> * 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)
>>=20
>> 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
>>=20
>> * Mnemonic table aliases. No more meaningless t0, t1, t2:
>>=20
>> 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 =3D
>> g.GALLERY_ID | selected:1 time_ms:0
>>=20
>> * No alias for single-table queries
>>=20
>> INFO cayenne-sql - SELECT ESTIMATED_PRICE, PAINTING_DESCRIPTION,
>> PAINTING_TITLE, ARTIST_ID, GALLERY_ID, PAINTING_ID FROM PAINTING |
>> selected:2 time_ms:0
>>=20
>>=20
>> (I am also thinking of lowercasing the SQL so that logs don't look =
like
>> they are screaming at you :))
>>=20
>> Andrus
>>=20
>>=20
>>=20
>>=20
>>=20