Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Standard name and value for "read-only" query hint #62

Open
lukasj opened this issue Jun 22, 2013 · 15 comments · May be fixed by #668
Open

Standard name and value for "read-only" query hint #62

lukasj opened this issue Jun 22, 2013 · 15 comments · May be fixed by #668
Labels
candidate-for-4 Good candidate for JPA 4 Priority: Major Type: Improvement

Comments

@lukasj
Copy link
Contributor

lukasj commented Jun 22, 2013

Relational databases typically benefit from the knowledge, whether a transation will potentially modify and information (so locks are needed), or only read-only queries are executed (so no locks are needed). For similar reason, EclipseLink (and hopefully other JPA implementations, too) know query hints for "ready-only".

Unfortunately when using such vendor-specific hints, this will induce the problem that a portable application must know all these hints for all JPA implementations (or there will be no Performance gain for the unknown ones). This is not smart from the view of an ISV.

Hence I want to propose that the next maintenance release of the JPA specification defines a unique name and value to enable the read-only query mode independently of the actual JPA implementation.

Proposal: A compliant implementation which has a read-only query mode MUST enable this read-only query mode when the "javax.persistence.readonly" with a value of "true" is provided.
@lukasj
Copy link
Contributor Author

lukasj commented Jun 22, 2013

@glassfishrobot Commented
Reported by mkarg

@lukasj
Copy link
Contributor Author

lukasj commented Dec 9, 2015

@glassfishrobot Commented
mkarg said:
I would really appreciate it if someone of the JPA spec team could at least comment on this more than two years old proposal.

@lukasj
Copy link
Contributor Author

lukasj commented Dec 11, 2015

@glassfishrobot Commented
@lukasj said:
this make sense to me. Should check if there are other useful/commonly used hints to be defined by the spec.

@lukasj
Copy link
Contributor Author

lukasj commented Dec 11, 2015

@glassfishrobot Commented
pbenedict said:
For clarity's sake, EclipseLink's "read-only" hint regards how it manages the first-level cache during a query; it's not about a making the transaction read-only.

@lukasj
Copy link
Contributor Author

lukasj commented Dec 11, 2015

@glassfishrobot Commented
mkarg said:
A general "read-only" JPA property should simply allow the application programmer to tell JPA that the result of the query will never get updated by the current transaction. Whetever conclusions a JPA implementation draws from this is completely up to the particular JPA implementation. If EclipseLink simply uses this internally for its own cache purposes, this is a valid use. Other implementations might additionally or instead use this flag to send a "FOR READ ONLY" hint to the JDBC driver so the database can relax locking, etc.

@lukasj
Copy link
Contributor Author

lukasj commented May 5, 2017

@glassfishrobot Commented
This issue was imported from java.net JIRA JPA_SPEC-62

@lukasj
Copy link
Contributor Author

lukasj commented Aug 1, 2018

@mkarg Commented
I can't believe it is five years since i reported it. Are there any plans to add this reall small change?

@lukasj
Copy link
Contributor Author

lukasj commented Aug 31, 2018

@mkarg
Copy link

mkarg commented Aug 31, 2018

@mkarg I was the original reporter.

@gavinking
Copy link
Contributor

gavinking commented Aug 10, 2023 •
edited
Loading

For clarity's sake, EclipseLink's "read-only" hint regards how it manages the first-level cache during a query; it's not about a making the transaction read-only.

Hibernate has a very similar feature, with a very similar semantic.

So this is definitely something we should discuss standardizing at some stage. (However, I would advocate doing it in a more typesafe way, not via a stringly-typed hint.)

@gavinking
Copy link
Contributor

(However, I would advocate doing it in a more typesafe way, not via a stringly-typed hint.)

For example, if #454 goes through, it could be a FindOption.

@gavinking
Copy link
Contributor

Actually, if #454 does go through, I think we should even consider including this in 3.2.

@gavinking gavinking added the candidate-for-4 Good candidate for JPA 4 label Aug 23, 2023
@gavinking
Copy link
Contributor

Actually, if #454 does go through, I think we should even consider including this in 3.2.

Well, it did not make it into 3.2, but H7 introduces a ReadOnlyMode enum, which is a FindOption, which I think we should promote to the spec. We would also add setReadOnly() to Query.

gavinking added a commit to gavinking/persistence that referenced this issue Sep 20, 2024
@gavinking
introduce ManagedEntityMode
7137fe1 
finally addresses issue jakartaee#62

Signed-off-by: Gavin King <[email protected]>
@gavinking gavinking linked a pull request Sep 20, 2024 that will close this issue
Draft
@gavinking gavinking linked a pull request Sep 20, 2024 that will close this issue
introduce ManagedEntityMode #668
Draft
gavinking added a commit to gavinking/persistence that referenced this issue Sep 20, 2024
@gavinking
introduce ManagedEntityMode
8ddac32 
finally addresses issue jakartaee#62

Signed-off-by: Gavin King <[email protected]>
@gavinking
Copy link
Contributor

gavinking commented Sep 20, 2024 •
edited
Loading

In #668 I have proposed ManagedEntityMode and related APIs.

There are two open issues here:

  1. How "deep" is the effect of the ManagedEntityMode? Are eagerly-fetched associated entities also read-only? (I suppose they should be.)
  2. When happens when I request an entity a second time in a different mode? For example, does a second call to find() "override" the read-only mode of an already-loaded entity? (I think it should.)

@gavinking
Copy link
Contributor

A third question is:

  • when an entity is in read-only mode, do cascades still get processed at flush time? (I suppose they should not be.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
candidate-for-4 Good candidate for JPA 4 Priority: Major Type: Improvement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

introduce ManagedEntityMode gavinking/persistence
3 participants
@gavinking @lukasj @mkarg