Skip to content

Updates on migration topics Java/Node#2696

Merged
renejeglinsky merged 5 commits into
mainfrom
rjegl/node-migration
Jul 3, 2026
Merged

Updates on migration topics Java/Node#2696
renejeglinsky merged 5 commits into
mainfrom
rjegl/node-migration

Conversation

@renejeglinsky

@renejeglinsky renejeglinsky commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

These are some findings. Please use that as a trigger to check if more details around those changes are needed.

@renejeglinsky renejeglinsky changed the title Node: New defaults Updates on migration topics Java/Node Jun 29, 2026
Comment thread node.js/databases.md Outdated
Co-authored-by: sjvans <30337871+sjvans@users.noreply.github.com>
@renejeglinsky

Copy link
Copy Markdown
Contributor Author

I'll merge this for now, but @agoerler please follow up if needed

@renejeglinsky renejeglinsky merged commit 577a220 into main Jul 3, 2026
4 checks passed
@renejeglinsky renejeglinsky deleted the rjegl/node-migration branch July 3, 2026 11:42
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".

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@agoerler please check this one if this is sufficient

Comment thread java/security.md
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`.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BraunMatthias Please check if we need to adapt more on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants