Á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: - slow_transactional.zip (2.70 kB)
Comment From: spring-projects-issues
Á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.
Comment From: spring-projects-issues
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.
Comment From: bclozel
Closing as this doesn't point to any possible optimization.