Huge performance issue with @Transactional [SPR-15909]

[spring-projects-issues]

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

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

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

[bclozel]

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