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

Huge performance issue with @Transactional [SPR-15909] #20463

Closed
spring-projects-issues opened this issue Aug 30, 2017 · 3 comments
Closed

Huge performance issue with @Transactional [SPR-15909] #20463

spring-projects-issues opened this issue Aug 30, 2017 · 3 comments
Labels
in: data status: declined

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Aug 30, 2017

Ács Ádám opened SPR-15909 and commented

Enabling @Transaction on a spring service makes a method execution time 100x slower. I set up a minimum example, it shows the following:

1 spring bean + 1 pojo, both has a trivial method to execute. Mesured with spring stopwatch.

Without transaction:
pojo: 1ms
bean: 1ms

With transaction:
pojo: 1ms
bean: 89ms


Affects: 4.3.10

Attachments:

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 30, 2017

Ács Ádám commented

https://dzone.com/articles/cacheable-overhead-spring-0 article covers the issue. It's about caching, but the problem is identical in my opinion.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 30, 2017

Juergen Hoeller commented

As far as I can tell - and as far I can measure -, this is simply the transaction processing overhead that you're measuring against an essentially empty method there. There's also some general overhead of reflective invocations but most time is actually spent in the transaction management itself. Since most transactions are declared at service boundaries, the overhead only occurs in specific spots, not for each level of invocation in a call stack.

None of this usually matters with real-life transactions since such actual service method code involves a degree of I/O which outweighs the transaction overhead by far. And if you really care, there's always programmatic transaction management a la TransactionTemplate as an alternative, with somewhat reduced overhead. That's also what I would recommend for plain cache access: If you care about hotspot overhead, use programmatic cache access.

Of course, if we can identify specific optimizations here, we're happy to consider them.

@spring-projects-issues spring-projects-issues added status: waiting-for-triage in: data type: enhancement and removed type: enhancement labels Jan 11, 2019
@bclozel
Copy link
Member

@bclozel bclozel commented Feb 18, 2022

Closing as this doesn't point to any possible optimization.

@bclozel bclozel closed this as completed Feb 18, 2022
@bclozel bclozel added status: declined and removed status: waiting-for-triage labels Feb 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data status: declined
Projects
None yet
Development

No branches or pull requests

2 participants