better use case and good delivery. thank you for this atomic featured videos. it will change the way we knew about what we already knew. it's great please put this video in to a atomic features playlist.
All well and good using this in your service layer, but how will this work with clean architecture? The service layer would be replaced by the Domain layer and we all know the domain layer has zero dependencies on any other layer such as the outer spring layers etc. How would implement transactional behaviour using clean architecture and even things like cascade?
Maybe a solution is to have the controller call a dumb Service such as PersonService which contains the PersonUseCase. When the client calls PersonService.save() the save() method within the PersonService will have the @Transaction annotation and then the next line of code within PersonService.save() will be personUseCase.execute(). This way we simply delegate to the usecase where the business logic lives and at the same time it is transactional?
@Valid and @Validate are JPA annotations, so that is a different use case, and will throw exception at the controller during binding, won't even go to Service layer.
lol. Your initial example is totally differently to the one you implement. It is a totally different problem to the code you implement. so how do you manage concurrent buyers after one book? Sorry what you describe at the start is not a transaction. The book being sold when the buy button is pressed is the transaction.
![Acer Aspire Lite 12th Gen Core i5-12450H Vs Lenovo Thinkbook 16 G6 Amd Ryzen 5 7530u Laptop [Hindi]](http://i.ytimg.com/vi/vZObhKgw3Hw/mqdefault.jpg)
![Kumamoto Masters Japan 2024 | Gregoria Mariska Tunjung (INA) [5] vs. Akane Yamaguchi (JPN) [2] | F](http://i.ytimg.com/vi/EIjZybhsWqA/mqdefault.jpg)
Top video. Didn’t understand the annotation until this!
Same here. I use it but I don't understand it and I have been asked in interview before.
you are the best, i wish you'd have more subs and continue doing the thing you love
Nice and detailed explanation. Just subscribed.
Very nice explanation.
I love the fact that you use actual UML subscribed.
Thanks for bringing great and simple examples to things sometimes kinda "obscure" like @Transactions!
better use case and good delivery. thank you for this atomic featured videos. it will change the way we knew about what we already knew. it's great please put this video in to a atomic features playlist.
That's very helpful, I like your videos 🔥
learn a lot thanks for the explanation.
I have subscribed and hit the like button
Great Explanation!!
great explanation ❤👍👍
helpful content, thanks
great job. keep the good work !
Thanks man. Pretty nice content!
Great explanation, as in your other videos.
Your new subscriber ❤🎉
may be you can add introduction to the Saga pattern for distributed transactions and how to use it in Spring Boot app ?
Why did you declare a generator in the Entity class and then again in the migration?
All well and good using this in your service layer, but how will this work with clean architecture? The service layer would be replaced by the Domain layer and we all know the domain layer has zero dependencies on any other layer such as the outer spring layers etc. How would implement transactional behaviour using clean architecture and even things like cascade?
Maybe a solution is to have the controller call a dumb Service such as PersonService which contains the PersonUseCase. When the client calls PersonService.save() the save() method within the PersonService will have the @Transaction annotation and then the next line of code within PersonService.save() will be personUseCase.execute(). This way we simply delegate to the usecase where the business logic lives and at the same time it is transactional?
Do i need to add Transaction Manger @Bean in the @Configuration class or is it autowired for us with Mysql / Postgres dependency or something?
Thank you so much 🙏
PlatfformTransactionManager bean is auto configured. So it will work out of the box, But like everything you can override if required.
Does @validate also make the action atomic?
Does it save non-validated requests?
@Valid and @Validate are JPA annotations, so that is a different use case, and will throw exception at the controller during binding, won't even go to Service layer.
lol. Your initial example is totally differently to the one you implement. It is a totally different problem to the code you implement.
so how do you manage concurrent buyers after one book? Sorry what you describe at the start is not a transaction. The book being sold when the buy button is pressed is the transaction.