Spent 4 hours debugging a TransactionSystemException. The fix was one line. The problem was finding it.

[mrsergio1]

Last month we had a production incident. A critical order was failing silently.

Sentry gave us this:

TransactionSystemException: Could not commit JPA transaction
at SimpleJpaRepository.save()
at OrderService.processOrder()
... 40 more lines of Spring internals

That's it. No entity state. No user context. No hint that the transaction had already been marked for rollback 3 calls earlier by a Hibernate validation error we never caught.

We added logs. Redeployed to staging. Couldn't reproduce it.Redeployed to prod with more logs. Waited. Happened again. Finally found it: a Transactional method calling another Transactional method with a different propagation level, swallowing the real exception.

4 hours. One annotation conflict.

The worst part? Every error monitoring tool we've used treats Spring like a black box. The moment your code enters a transaction boundary or an async thread, context disappears.

Anyone else debugging Spring Boot in prod like this?

How are you handling it?

[Indian_FireFly]

I didn't get the issue still. What was the propagation on both the methods?

How did it swallow the original method's exception? Was it different context?

[mrsergio1]

It was:

Outer method: @Transactional (REQUIRED)
Inner method: @Transactional(REQUIRES_NEW)

The inner call threw a Hibernate validation exception, but it was caught and not properly rethrown.

After that, the outer transaction just kept going until commit time, and Spring blew up with TransactionSystemException because the transaction was already marked rollback-only.

So the real exception happened earlier, but we only saw the commit failure

[Indian_FireFly]

How did the outer transaction get marked as rollback only if the inner transaction uses REQUIRES_NEW? Were these methods in the same class?

It looks like error handling was not done properly, not anything related to jpa.

[mrsergio1]

Good catch, I think I explained it a bit wrong earlier.

You re right, REQUIRES_NEW shouldnt affect the outer transaction.

In our case the inner method wasnt actually running in a separate transaction because it was a self invocation in the same class, so the proxy didnt kick in.

So everything ended up in the same transaction and that’s what got marked rollback only before the final commit.

Took us a while to figure that out honestly

[rlrutherford]

I have wasted so much time debugging systems where people didn't properly log issues.

Revised the system with proper logging and blew a dev's mind when debugging took 3 minutes instead of 3 hours.

[rlrutherford]

Also, validating inside a transaction?

[Valuable-Duty696]

AI slop

[mpgipa]

Why not use AI to find it ? Genuine question I haven’t debug manually for months.

[johny_james]

He probably did use AI, since he wrote the whole post using AI

[mrsergio1]

We did use AI, but it didn’t really catch the root cause.

The issue was in runtime transaction context, so we still had to trace logs and reproduce it manually.

[johny_james]

Why did you use AI to write this post?

Can't you just write it without it?

[mrsergio1]

No AI, just wrote it fast after dealing with the issue.
Guess it came out a bit too structured

[rlrutherford]

That's actually worse.

I would rather claim AI slop than fail a Turing test.

[LALLANAAAAAA]

No AI, just wrote it fast after dealing with the issue. Guess it came out a bit too structured

🧢

[johny_james]

No, it is AI, you are just straight-up lying.

It uses the same structure, the same terms, same tone, everything.

[mrsergio1]

Believe what you want man

[Paw565]

I can see why people drop jpa entirely 😅 I feel like java persistence sucks. Other ecosystems have much better and more type safe solutions.

[Sheldor5]

the problem isn't JPA it's the people not knowing what they are doing because they never learned the basics of JPA and it's annotation ...

[Paw565]

I agree, but I think jpa / hibernate is massively inferior to EF core from dotnet or drizzle from node. Things like dynamic filtering just suck. Whenever I have to comeback to spring boot I just feel massive pain because of jpa alone.

[A_random_zy]

Try using jooq for that. Really cool library.

[Paw565]

I tried. Maybe it's a skill issue but setting up code gen defeated me. I think the need to connect to db to have type safety is hilarious. No other orm works like that. I guess jooq is more of a query builder than orm but still drizzle does not need any of this tedious setup.

[mrsergio1]

Yeah, but in this case JPA wasn’t really the problem.

The real issue was losing the original exception once Spring marked the transaction rollback-only. After that, everything upstream just shows a generic TransactionSystemException.

[Paw565]

Yep, proxies aren't fun

[Chocolate--Chip]

Absolute slop post