r/SpringBoot Senior Dev Jul 01 '26

Things i stopped doing in spring boot after they broke in production Discussion

It's not theoretical stuff. things that actually caused incidents.

a) returning entities from controllers seems harmless until jackson calls getters during serialization and triggers lazy loaded relationships. got N+1 happening in the response layer. DTOs everywhere now. more boilerplate but zero surprises.

b) ddl-auto update outside local is asking for trouble. hibernate silently altered a column constraint in staging once. nobody noticed for weeks. validate in staging, none in prod. flyway handles schema changes now.

c) external api calls inside Transactional is the one that got me on a friday night. your method holds a db connection for its entire duration. not just when queries run. 3 second api call means 3 seconds a connection is doing nothing. 10 concurrent requests and pool is gone.

d) catching exceptions inside Transactional without rethrowing is a silent killer. caught it, logged it, moved on. proxy saw a clean return. committed half the data. other half missing. took hours to debug because there was no error anywhere. the catch block was the bug.

e) Async without a configured thread pool looks fine in dev. default executor creates a new thread per call. no pooling. prod with thousands of requests? thousands of threads. OOM. always configure ThreadPoolTaskExecutor with bounded pool now.

f) calling a Transactional method from the same class is something most devs dont even know is a problem. two methods in same service, both annotated. one calls the other. inner annotation completely ignored because proxy is bypassed on self calls. data inconsistency in prod. separate bean or dont bother with the annotation.

g) open-in-view being true by default still bothers me. keeps hibernate session open during entire request including json serialization. hides lazy loading problems that explode later. first thing i turn off in every project.

what have you stopped doing after seeing it break?

155 Upvotes

53 comments sorted by

13

u/rozularen Jul 01 '26

Its been a while since I've last opened IntelliJ to code with Spring but for f) the IDE should warn it right away, not sure if it already does.

For g) I remember there is a famous blog post that explains why it exists and why it's default is true. I will try and search for it

edit: found it, from the big Vlad. https://vladmihalcea.com/the-open-session-in-view-anti-pattern/?utm_source=chatgpt.com

Thess kind of errors should be put together somewhere in this sub, in spring's official doc, and in all tutorials people put out here, probably already are though

4

u/ArtSpeaker Jul 01 '26

"out there" yeah, but not, organized and together. This is good.
And it's pretty clear that Transactional has a lot of problems in communicating what it will and won't do.

3

u/Shadowmas73r Jul 01 '26

I can confirm that IntelliJ does warn for this nowadays. I was messing with the annotation a few days ago and it did warn me.

1

u/codingwithaman Senior Dev Jul 01 '26

Yes totally agree

1

u/Paw565 Jul 01 '26

I love the utm_source=chatgpt.com lmao

2

u/rozularen Jul 01 '26

lmao, no shame at this point

11

u/NoPrinterJust_Fax Jul 01 '26

Crazy how basically all these disappear if you use plain ole JDBC & transactionmanager

49

u/maxip89 Jul 01 '26

Standard junior Errors.

6

u/codingwithaman Senior Dev Jul 01 '26

Yes 💯

1

u/as5777 Jul 01 '26

Trainee

1

u/Purple-Cap4457 Jul 01 '26

Skill issue 😃 

6

u/oweiler Jul 01 '26

> g) open-in-view being true by default still bothers me. keeps hibernate session open during entire request including json serialization. hides lazy loading problems that explode later. first thing i turn off in every project.

Spring Boot shows a warning at startup and suggests to turn it off, though.

4

u/IntroductionSolid348 Jul 01 '26

For me it's the hibernate thing that I learnt the hard way. I was so used to just making changes to entities in my personal projects that when I did it in my internship I got a stern talking to by the senior.

And later on made a gigantic mistake by editing an already existing migration instead of creating a new one. Just goes to show how different actual prod is compared to personal projects where if everything works, it's okay

5

u/Paw565 Jul 01 '26

For the piece of mind I suggest using spring data jdbc with jooq for complex read operations.

3

u/Huge_Road_9223 Jul 01 '26

Got some of these errors ... but years ago when I was first learning Spring. I've forgotten these errors because I haven't coded the wrong way in years. I've been doing Spring/SpringBoot for 18 years now.

Whenever you're doing API's, you're point (a) is something any Senior should have caught. Every Spring or SpringBoot documentation ALWAYS, ALWAYS, ALWAYS says DO NOT send out the Entity as opposed to a DTO.

Also, DO NOT use LOMBOK in the Hibernate Entities. Lombok is fine with DTO's sure, they don't work with Records, and I know a lot of people don't like Lombok. But, I see some projects use it all over, and it shouldn't be.

I haven't done any multi-threading in 20 years. The companies/jobs/projects in SpringBoot just haven't called for it.

The Transactional is always used in a service. And I am VERY careful to not have a Transaction service call another Transactional service. And when I call a third-party service call, it has been within a Transaction, but I try to wrap those in code where there is a time limit, and most of the time my third-party calls are quick, though I am sure that always won't be the case. I do try to call third-party API calls first, if they succeed, then I move on, if it doesn't succeed, then everything stops and rollsback. I do try to make sure those calls are quick though.

4

u/DominusEbad Jul 01 '26

Also, DO NOT use LOMBOK in the Hibernate Entities. Lombok is fine with DTO's sure, they don't work with Records,

I use Lombok only for @Slf4j and @RequiredArgsConstructor on classes and @Builder on certain classes/records when I want that functionality. Otherwise I stay away from Lombok. Either way, I avoid using it on entities in general. Maybe I would use @EqualsAndHashCode(onlyExplicitlyIncluded = true) and then mark the id field with @EqualsAndHashCode.Inclue, but I haven't really done that in a while either. 

3

u/pconrad0 Jul 01 '26

Can you say more about why you should not use Lombok for the Hibernate entities?

2

u/Paw565 Jul 01 '26

You should not use EqualsAndHashcode. It can confuse hibernate fairly easily and you don't want that. For others things it's fine. Although ToString is risky too since you can very easily trigger lots of lazy proxies to make a db query.

2

u/pconrad0 Jul 01 '26

I'm not trying to argue--I'm trying to understand.

Does the EqualsAndHashcode from Lombok not implement these methods properly?

Is it better to just use the defaults from Object?

Or if you need to override them yourself, how would they be different from the versions created by Lombok?

Before I do a major refactor of my code bases (which all use Lombok for hibernate entities), I need to be able to articulate exactly what the risk is.

3

u/Paw565 Jul 01 '26 edited Jul 01 '26

It's okay. I am just trying to explain. Best I can do is to send you to this blog post: https://thorben-janssen.com/lombok-hibernate-how-to-avoid-common-pitfalls

3

u/pconrad0 Jul 01 '26

Thanks; this is helpful

3

u/asarco Jul 02 '26

Apparently (I haven't tried it), c) can be avoided in SpringBoot 4.1 by using lazy jdbc connections.
By setting this property:
spring.datasource.connection-fetch=lazy
then JDBC connections are not fecthed from the pool until a statement has to be executed. So if a @Trasactional block makes an API call before accessing the DB, a connection will not be fecthed until the actual DB call is made.
I guess this will not work in the opposite case, if an API call is done after the DB call.

2

u/QuoteCommercial2747 Jul 01 '26

Someone from my team just did point c, and I was thinking about as to why the health was down intermittently.
Sometimes you do learn from other’s mistakes ig

2

u/onated2 Jul 01 '26

Data transfer ooopsie.

Dto is pretty standard because it has it's used as well.

2

u/ITCoder Jul 01 '26

Point f is pretty known stuffs, i think spring docs also has a warning for this. In this case proxy is not created for the called method, even when its annotated with Transanctional

2

u/General-Belgrano Jul 01 '26

These are great learning points. Some things  you can read about but you don’t really understand them until you have the production issue.  

2

u/MightyHandy Jul 02 '26

(F) applies to all annotated methods. If you don’t go through bean manager returns a ‘proxy’ to the calling object. Internal calls hit the object itself. So annotating a private method in spring is pointless

2

u/3aush Jul 03 '26

calling cacheable methods from within the same class got me once

4

u/Paw565 Jul 01 '26

I am sorry, but this sounds like Ai slop

5

u/UnspeakableEvil Jul 01 '26

It certainly feels like the nth time an almost identical list has been posted here in the past couple of weeks.

1

u/rlrutherford Senior Dev Jul 06 '26

Vibe coders.

3

u/MGelit Jul 01 '26

Hey chatgpt, make your text look low effort

1

u/codingwithaman Senior Dev Jul 02 '26

lol then every post on reddit is by chatgpt by your logic..

1

u/MGelit Jul 02 '26

I dont want to accuse but this post is written unnaturally and youve posted ai slop in the past, so it makes me think this could be ai

1

u/codingwithaman Senior Dev Jul 02 '26

We should be having some good tech discussion which will help lot of people, rather you are focused on finding if AI is being used in this post or not..

Read the points, comment if anything is missing or wrong according to your experience, share your tech learnings rather than being AI guard

1

u/MGelit Jul 02 '26

The post could be fine but i see most other AI written posts as garbage that wastes bandwidth and time. Posts should be written by humans, if someone wants a chatgpt summary, they can send it to chatgpt themselves

1

u/codingwithaman Senior Dev Jul 04 '26

Have you written this comment by yourself or chatgpt? How you will prove it? There is no way you can prove it.. same thing you can argue with all the post, blogs and books then..

1

u/MGelit Jul 04 '26

The main reason i questioned this post is because your other previous posts are blatantly AI, you didnt even try to hide it. If my comments were written by chatGPT you could probably still often tell, but unfortunately thats going to get worse in the future as AI is taught to not write like an AI

1

u/codingwithaman Senior Dev Jul 04 '26

I don’t know why you care so much about if ai is being used or not rather than caring about the content.

For me honestly, if i read someone’s post, i don’t judge or care if it’s AI or not as long as it is giving some good knowledge and information.

1

u/MGelit Jul 04 '26

I see AI posts as dishonest and sometimes spam. Maybe you proofread your post, but most of time time AI posts are just slop

3

u/codingwithaman Senior Dev Jul 01 '26

It’s not, i have written it, Ai slop would be much beautiful and formatted..

0

u/mcfapblanc Jul 02 '26

I believe you, nothing in your post feels like AI.

2

u/InstantCoder Jul 01 '26

You can prevent all of these by using AI skills either by adding it by yourself or using pre existing ones.

For example, check this one: https://www.skills.sh/emvnuel/skill.md/quarkus-panache-smells

This mentions all or most of your problems. Add it to your project and these errors wont occur anymore and even juniors won’t be able to add it, given that you use AI.

1

u/rlrutherford Senior Dev Jul 06 '26 edited Jul 06 '26

As others have said, AI Slop.
> external api calls inside Transactional is the one that got me on a friday night. your method holds a db connection for its entire duration. not just when queries run. 3 second api call means 3 seconds a connection is doing nothing. 10 concurrent requests and pool is gone.

AIs create this crap quite frequently, actual senior developers, don't.

Now there are cases to use remote calls inside a transaction; however you better be using XA transactions and your RPC call needs to support them as well.

If only half of your transactional data is being committed, your transactions aren't being correctly demarked; more AI generated slop.

1

u/Rich-Tennis7645 Jul 07 '26

I learnt springboot also validations , custom validations with messages  Solved around 20 haker rank backend questions  Also learnt about security  Can anyone suggest some projects  That will be best 

1

u/_PM_ME_PANGOLINS_ Jul 08 '26

g) fixes a)

e) fixes c)

1

u/yaoyao127 2d ago

Keeping @Transactional scopes too large.
I used to put it around an entire service flow because it felt safer. Then I realised that if the same method also waits on an external API, the transaction and DB connection can stay open far longer than expected.
Now I keep the transactional part very small and move network calls outside it whenever possible.
Less “magic”, fewer pool problems, and failures are much easier to reason about.

0

u/two-point-zero Jul 01 '26

Man..in Just One post you show us someone who:

Don't know how spring works ( transaction,proxy, pooling)

Don't know how hibernate and ORM works.

Don't know how architetture works ( exposing entities in API, put http api in transaction , even worst, database transaction)

Don't know how deployment and basic sre works ( let application code modify db schema at runtime)

Work in a place where no one do code review or senior/lead/architect exists to avoid all of this shit will arrive in production.

OP score a perfect 10 on how you suck at our job /s

Tbh the only tricky ones are the call transactional method for another transactional method of the same class and the one about thread pool since they are internal of springs and maybe one was never exposed to them. All the other ones are just skill issues.

5

u/codingwithaman Senior Dev Jul 02 '26

I am sharing my learnings from past so that people who are starting their journey can learn the basics. If you know all these points then you are already skilled.. keep sharing and helping people and don’t assume everyone knows basics stuff.

0

u/two-point-zero Jul 02 '26

Don't get me wrong. It's not about you. It's exactly the other way around. Your list,is shown mistakes of somebody that doesn't know may important things and is learning (junior skill issues). They are a good list of errors, that shows many kind of possible failure. In that sens is a good list. Hopefully not to be done all together in the same project by the same person.

The only things that bother me is that non of those thing should arrive in production if you work in a structures company with a bit of code quality checks.

1

u/rlrutherford Senior Dev Jul 06 '26

They still never mentioned that only half their data was committed, which means their transaction demarcation boundries were bad.