Java: Updates on migration topics

java/event-handlers/changeset-contexts.md

@@ -173,7 +173,7 @@ public class SessionContextHandler implements EventHandler {
 CAP ensures that every interaction with a service is inside of a ChangeSet Context. However transactions are not started at that point in time yet.
 By default, any kind of first interaction with the Persistence Service will begin the transaction. Once a transaction has been started, a connection for that transaction is reserved from the connection pool. This connection is only returned to the connection pool on commit or rollback of the transaction.
 
-However, `READ` events which run simple Select queries don't actually require transactions in most cases. When setting the property `cds.persistence.changeSet.enforceTransactional` to `false` most Select queries do not cause a transaction to be started any longer. A connection for these queries is obtained from the connection pool and returned immediately after executing the queries on the database. This can increase throughput of an application, by making connections available for concurrent requests faster. As soon as a modifying statement is executed on the Persistence Service, a transaction is started. All subsequent Select queries will participate in that transaction. Note, that this behaviour is only transparent when using the default transaction isolation level "Read Committed".
+However, `READ` events which run simple Select queries don't actually require transactions in most cases. As the property `cds.persistence.changeSet.enforceTransactional` is `false` by default, most Select queries do not cause a transaction to be started any longer. A connection for these queries is obtained from the connection pool and returned immediately after executing the queries on the database. This can increase throughput of an application, by making connections available for concurrent requests faster. As soon as a modifying statement is executed on the Persistence Service, a transaction is started. All subsequent Select queries will participate in that transaction. Note, that this behaviour is only transparent when using the default transaction isolation level "Read Committed".
 
 A ChangeSet Context can always be marked as requiring a transaction, by calling the `markTransactional` on the `ChangeSetContext` or `ChangeSetContextRunner`. The next interaction with the Persistence Service will guarantee to start a transaction in that case. Alternatively, Spring Boot annotations `@Transactional` can be used to eagerly start a transaction.
 

java/migration.md

@@ -61,7 +61,7 @@ The following table lists the individual recipes provided by CAP for APIs that h
 |[c.s.c.s.m.MigrateStatements](../releases/2025/aug25#typed-query-results)|Migrates CQN statements to comply with typed Query API changes in 4.3.0.|4.3.0|
 
 
-## CAP Java 4.9 to CAP Java 5.0 (TBA) { #four-to-five }
+## CAP Java 4.9 to CAP Java 5.0  { #four-to-five }
 
 ### Spring Boot 4
 

java/security.md

@@ -94,10 +94,7 @@ The property `cds.security.authentication.mode` controls the strategy used for a
 | `model-strict` | Authentication is derived from the authorization annotations `@requires` and `@restrict`. If no such annotation is available, the endpoint is authenticated. An explicit `@requires: 'any'` makes the endpoint public (Default).
 | `always` | All endpoints require authentication.
 
-By default the authentication mode is set to `model-strict` to comply with secure-by-default.
-In that case you can use the annotation `@requires: 'any'` on service-level to make the service and its entities public again.
-You can only make an endpoint public if the full endpoint path is also considered public.
-For example you can only make an entity public, if the service that contains it is also considered public.
+By default the authentication mode is set to `model-relaxed`.
 
 ::: tip
 The authentication mode has no impact on the *authorization* behaviour.