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.

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

Improve performance with Propagation.SUPPORTS for readOnly operation [DATAJPA-601] #987

Closed
spring-projects-issues opened this issue Sep 1, 2014 · 7 comments
Assignees
Labels
in: core status: declined type: enhancement

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Sep 1, 2014

Grigory Kislin opened DATAJPA-601 and commented

According this article read only operation with JPA much more efficient in case of no transaction opened (in case of no outer transaction). So to improve performance it is needed to declare
@Transactional(readOnly = true, propagation=Propagation.SUPPORTS) in all read only operation with JPA, e.g.

@Transactional(readOnly = true, propagation=Propagation.SUPPORTS)
public class SimpleJpaRepository<T, ID extends Serializable> ...

Affects: 1.7 GA (Evans)

Reference URL: http://www.ibm.com/developerworks/library/j-ts1/

Issue Links:

  • DATAJPA-1210 Discuss about the optimization of read-only transactions
    ("is duplicated by")

Referenced from: pull request #126, and commits 965c252, c5bfb30, b53591b, 25c9bfb

0 votes, 5 watchers

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 1, 2014

Juergen Hoeller commented

So what specifically are you asking for? A change of defaults in Spring Data JPA, in which case we'd have to move this issue to the Spring Data project?

Juergen

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 1, 2014

Grigory Kislin commented

Hello. Yes it is bug for Spring Data JPA project and when I open it there was Spring Data JPA title.
Please move it there

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 25, 2014

Grigory Kislin commented

As this improvement related to ALL @Transactional(readOnly = true)
read operation and performance issue is very important I change priority to Major

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 26, 2014

Thomas Darimont commented

I gave this a spin - see remarks in the PR - looks like a useful change.

This change uses a different code path in org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(TransactionDefinition). than before.
We now hit the case:
"// Create "empty" transaction"
which avoids the creation of a new tx.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 27, 2014

Oliver Drotbohm commented

I am strongly opposing this one for a few reasons:

  1. It's by no means clear that the change would actually improve performance. There's multiple aspects in this. First of them is that the linked article is dated and incredibly flawed as it aggressively simplifies things. I can go into details if you want but I'll leave it at that for now. There are a lot of things playing into execution performance here. Without a transaction in progress neither the readOnly flag is propagated to the JDBC driver (which would cause optimizations for a lot of databases not being applied) nor would you apply the optimizations in Spring's JPA resource management code like explicitly turning off flushing, which - if applied - can dramatically improve performance in case you read a lot of data.

  2. There are means to tweak the default behavior already. The default transaction behavior can be tweaked on the repository interface declarations. Using @Transactional on the repository you can configure the transaction settings that are used during the execution of methods of the entire type hierarchy.

That said, we usually see people to define their own transaction boundaries on the service layer. Service methods usually provide a more adequate level of transaction granularity which leaves you yet another knob to tweak the behavior according to your needs

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Dec 1, 2014

Grigory Kislin commented

Hello Oliver!
About #1 I've found some resource, proven you opinion:
https://developer.jboss.org/wiki/Non-transactionalDataAccessAndTheAuto-commitMode
http://www.codeinstructions.com/2009/04/read-only-transactions-with-spring-and.html

Concerning #2 I fully agree: user always can change transaction behavior at service layer.
Mark Repository layer by @Transactional is rather feature of Spring Data project to simplify developer life. Please correct me, if I mistaken.

So, I suppose ticket could be closed.
Thanks and best regards,
Grigory.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented May 22, 2019

Jens Schauder commented

Batch closing resolved issue without a fix version and a resolution indicating that there is nothing to release (Won't fix, Invalid ...)

@spring-projects-issues spring-projects-issues added status: declined type: enhancement in: core labels Dec 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: declined type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants