ARTICLE AD BOX
QUESTION 1. Is calling repository.save(entity) necessary in this case?
ANSWER: No, It's not required if the entity is managed.
DESCRIPTION:
If you Fetch the entity inside a @Transactional method, Modify its fields or Do not detach it, then Hibernate’s dirty checking will automatically detect changes and flush them at transaction commit.
You need repository.save() when Creating a new entity, Working with a detached entity, Outside a transactional context and Using merge() semantics intentionally.
QUESTION 2: Is avoiding save() best practice or just optimization?
ANSWER: This is not just optimization — it’s correct usage of JPA’s persistence context.
DESCRIPTION:
Calling save() on a managed entity is redundant, adds confusion, may trigger unnecessary merge(), shows misunderstanding of JPA lifecycle.
No save() is the cleanest and most idiomatic JPA usage.
QUESTION 3: Does @Transactional improve performance?
ANSWER: Not directly.It is primarily for consistency, atomicity, isolation, proper session management and lazy loading support.
DESCRIPTION:
What @Transactional Actually Does When applied opens a transaction, binds Hibernate session to the thread, enables dirty checking and commits or rolls back properly.
when without @Transactional each query may run in auto-commit mode, no managed persistence context, dirty checking won’t work and lazy loading fails.
So, @Transactional does NOT make code faster by itself, But it prevents bad performance patterns,
