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

[lukasj]

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]

• Issue Imported From: https://github.com/javaee/jpa-spec/issues/62
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[lukasj]

@glassfishrobot Commented Reported by mkarg

[lukasj]

@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]

@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]

@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]

@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]

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

[lukasj]

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

[mkarg]

@mkarg I was the original reporter.

[gavinking]

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]

(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]

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

[gavinking]

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]

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]

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.)