Thanks Rafael! especially for the SKIP_LOCKED feature, new knowledge learnt
@RafaelPonte5 ай бұрын
Thank you so much! I am glad the talk was helpful for you! 🥰 And yeah, SKIP LOCKED is fantastic!! 💪🏻
@eduardo1201555 ай бұрын
Congratulations on your presentation! You absolutely nailed it. Your thorough research and confident delivery captivated everyone in the room. Your ability to explain complex ideas so clearly is truly impressive. Keep up the fantastic work!
@RafaelPonte5 ай бұрын
Thanks for the kind words, Eduardo! ❤
@RaphaelDeLio5 ай бұрын
Parabéns, Rafael! Foi um prazer assistir sua apresentação pessoalmente!
@RafaelPonte5 ай бұрын
Obrigado demais, Rapha! ❤ Você eh top!
@terteseamos5794 ай бұрын
this for me is the best presentation. Great job
@RafaelPonte4 ай бұрын
What a comment! Thanks for that! ❤️
@codeisma5 ай бұрын
Great talk! There are a few Java libraries that already solve these challenges (db-scheduler, JobRunr or Quartz). At JobRunr we'd love to share your talk as it explains JobRunr's architecture well and can help our users understand the challenges of distributed scheduling even better!
@RafaelPonte5 ай бұрын
Thanks for your comment! I'm glad you liked it! ☺ Please, I would appreciate it if you shared it! By the way, I received great feedback from Ronald, the creator of JobRunr-he watched my talk! He is a fantastic guy! ❤
@RonaldDehuysser5 ай бұрын
@@RafaelPonte You're too kind 🤩!
@RafaelPonte5 ай бұрын
@marshall143Thanks for the comment! 😊 I didn't know nFlow, but I understand that if your context allows your team or project to adopt a task scheduler or workflow engine, you should go with it. Usually, those libs and frameworks make the developer's life easier because they address very well all the issues discussed in the talk.
@YZ-ix3dn4 ай бұрын
Thank you for clear and well-structured presentation. It's very useful and important information even for people with lots years of experience. I wish every developer should watch this video when every time they put @Transactional onto theirs method.
@RafaelPonte4 ай бұрын
Thanks for the kind words! I am glad you enjoyed the talk! ☺
@felipedossantos72464 ай бұрын
I've seen this presentation in portuguese before of Rafael Pontes in Zup Channel, and I could implement something similar it in my job. Great work, Bro! Thank you so much
@RafaelPonte4 ай бұрын
Hi Felipe, Thanks for this comment and for having watched both versions of the talk. ❤
@danielponte31345 ай бұрын
Parabéns meu irmão , você deu um show na apresentação, impecável! show de top!
@RafaelPonte5 ай бұрын
Obrigado, meu irmão!
@hirenpandit84995 ай бұрын
Great talk!! so much learnings and addressed real life problems I faced while writing background scheduled jobs... btw we used ShedLock library but this is real good insight.
@RafaelPonte5 ай бұрын
Thanks! Nice you liked it!! 😊 By the way, ShedLock is a very cool library! 👊🏻
@bkavun4 ай бұрын
Great presentation, great work. Thanks a lot for sharing this knowledge with us!
@RafaelPonte4 ай бұрын
Thanks so much! I am glad you liked it 🥳
@popastefan65423 ай бұрын
36:48 Actually in our example, each instance will fight for first 50 records, not one record as it is illustrated in the slide.
@RafaelPonte3 ай бұрын
Thanks for the comment. Yeah, you're right. The number of rows is unimportant in understanding how the SQL feature works. The idea was to be didactic and straightforward.
@ferlezcano5 ай бұрын
Excellent topic! Have some background jobs running here and there and I definitely going to check them again.
@RafaelPonte5 ай бұрын
Nice! I am glad this talk was helpful to you! 👊🏻
@matthewmoore59344 ай бұрын
Great talk! A couple of thoughts. Your statement about entity state and transactions is only true if Spring's "open session in view" is not enabled. I find there is a lot of confusion out there about the Hibernate session, transaction state, OSIV, and entity state. Along similar lines, the call to a repository save() method is unnecessary when updating an attached entity because of Hibernate change tracking, and calling save() leads people to assume that it persists changes, which (counterintuitively) it doesn't. (It adds/merges detached entities to the session/persistence context.) Regarding transaction scope, I would argue it is still too broad. Work for a single user/card should generally happen in its own transaction, at least in an OLTP context.
@RafaelPonte4 ай бұрын
You are welcome! Thanks for the comment ☺️ I am unsure if I followed your comment about Open Session in View. I mean, there's no OSIV relation to a job scheduled by Spring since OSIV has to do with web/MVC scope. The code in the talk is correct. You are right about the save() method; it wasn't needed, but the idea was to show a simple and didact code, not getting into details about how to persist entities or their state transitions. The transaction scope is broader because we are working in batches 😊
@matthewmoore59344 ай бұрын
@@RafaelPonte Thanks for the response. I spend much time working in a WebMVC context that (unfortunately) uses OSIV and I'm too used to its oddities. 🙂
@gjperes15 ай бұрын
O Rafael é fera demais!! Great presentation
@RafaelPonte5 ай бұрын
Brigadão!! ☺
@hamedalipour10125 ай бұрын
you are an amazing presenter thank you so much learned a lot
@RafaelPonte5 ай бұрын
Thank you so much!!! I am happy this talk was helpful for you 🥳
@jesprotech5 ай бұрын
I really like the way you explained short running transactions. Nice addition to the jobs! Parabéns pela excelente apresentação! É muito útil!
@RafaelPonte5 ай бұрын
Thanks so much! I am glad you liked it 🥰
@HariharanIyer5 ай бұрын
Great talk and lot of cool new (for me) information about Spring/JPA semantics! But not much of this is specific to background jobs, and not much in the talk about generic background job processing. So I'd say the title is a bit misleading.
@RafaelPonte5 ай бұрын
Thanks for the comment 😊 I am glad the content was helpful for you! Out of curiosity, what do you understand as background jobs and job processing, and what do you expect from a talk about these subjects?
@pavanerbeck234 ай бұрын
Nicely done @RafaelPonte.
@RafaelPonte4 ай бұрын
Thank you! ☺
@jessilyneh5 ай бұрын
Congrats for your amazing presentation, Rafa!
@RafaelPonte5 ай бұрын
Thanks, Jess! ❤
@paulorcv3 ай бұрын
Very good! thank your for the valuable content!
@RafaelPonte3 ай бұрын
You are welcome 🤗
@CodingForRealLife3 ай бұрын
Amazing persentation, very usefull, thanks Rafael!
@RafaelPonte3 ай бұрын
You are welcome! 😊
@mindcontrolkmc.32864 ай бұрын
Really great talk! But I am curious that if 2 save statements already wrap in 1 small transaction how can it combine with the hibernate batch with another save statement process
@RafaelPonte4 ай бұрын
Thanks for the comment and feedback 😊 I am not sure if I understood your question correctly. Could you elaborate a little bit more on it?
@mindcontrolkmc.32864 ай бұрын
Hi Rafael, In the scenario of this video, we are using short-transaction to save data to the database so I think each transaction should be isolated so they can't be wrapped in one batch like your example INSERT INTO ... Values (A),(B)
@RafaelPonte4 ай бұрын
@@mindcontrolkmc.3286 Yeah, the idea is precisely that! For each batch (chunk) of 50 rows, Hibernate will group (and reorder if needed) each INSERT and UPDATE inside that short-running transaction and convert them into only two single statements right on the commit.
@BlindVirtuoso24 күн бұрын
Nice one. Appreciate it.
@RafaelPonte24 күн бұрын
Thanks! I am glad you liked it ☺️
@satishakumar1073Ай бұрын
Perfect
@RafaelPonteАй бұрын
Thanks 🙏🏻
@lobaorn5 ай бұрын
Congrats Rafael! Parabéns Rafa!
@RafaelPonte5 ай бұрын
Thanks so much!!! 🥰
@aleksandrS38944 ай бұрын
Does a single @Transactional annotation for Scheduled method (in case of JPA framework) fix the original code right away?
@RafaelPonte4 ай бұрын
Thanks for the comment. It depends on which problem you're talking about. In the talk’s context, it solves only part of the problem: it makes the whole operation atomic and recoverable but causes a few side effects.
@duyetpham79245 ай бұрын
Beautiful presentation, thank you
@RafaelPonte5 ай бұрын
Thank you so much! That's very nice you liked it! 🥰
@YuliSlabko5 ай бұрын
Nice explanation! But did not cover very important case if your app has more than one job marked with @Scheduled annotation. Because it may be crucial moment of performance. May be it will be covered in next topics.
@RafaelPonte5 ай бұрын
Thanks for the comment 😊 Nice you liked it! I am not sure if I understood what you mean. Usually, a single application has multiple @Scheduled jobs running concurrently doing different things (sometimes at other times). Could you give more details?
@YuliSlabko5 ай бұрын
@@RafaelPonte If you do not specify in application.yml thread pool size for scheduler explicitly all jobs will be operated by one single thread.
@RafaelPonte5 ай бұрын
@@YuliSlabko Thanks for the explanation. Now I got your point! ☺ You're right. If your application runs multiple jobs close together or jobs that take too long to finish, tuning the Scheduler's thread pool size is essential. 👊🏻
@victoralcantara84705 ай бұрын
Amazing! Congrats Rafa!
@RafaelPonte5 ай бұрын
Thanks, I'm glad you liked it ☺
@Cassitu5 ай бұрын
Parabeeens manooo! ficou top! sucesso
@RafaelPonte5 ай бұрын
Obrigado! Feliz que curtiu ❤
@knoppix203 ай бұрын
26:34, 31:59, 32:14, 36:04, 40:31 - key moments
@RafaelPonte3 ай бұрын
Thanks for the comment and for pointing out the key moments ☺️
@SarkhanTakhirov5 ай бұрын
what's the difference between reading and writing with a rabbit or kafka and reading and writing with a database? Usually i'm using REDIS for solve same problem, because it much faster than usual relation db
@RafaelPonte5 ай бұрын
Thanks for the comment. I will ignore the trade-offs of having a new component in the infrastructure now and focus only on the developer's perspective. There are differences, but how they can impact your solution depends on your context. I mean, using Kafka or RabbitMQ in the talk's job perspective may have little difference on the job's code, but in the application perspective, which produces events in the queue, we may have to deal with a dual write issue. The same is true for Redis: it depends on how you're using it, such as a distributed lock provider or a message queue.
@JuniorAdy105 ай бұрын
Braaabo de mais. Parabéns, príncipe do oceano kkk 👏👏👏
@RafaelPonte5 ай бұрын
Brigadão, Junior! 👊🏻
@benicioavila5 ай бұрын
@@RafaelPonte Parabéns Rafael! Compartilhando com todos do meu time! Abraço.
@RafaelPonte5 ай бұрын
@@benicioavila obrigado ☺️ E valeu por compartilhar!! ❤️
@TTT-z2l5 ай бұрын
Great talk! Did not catch all the red flags in this :)
@RafaelPonte5 ай бұрын
Thanks! I am glad you liked it!! ❤
@annabeatrizelias96895 ай бұрын
Parabéns, muito show!
@tahahajivand18433 ай бұрын
it was so good. thanks
@RafaelPonte3 ай бұрын
I am glad you liked 😊
@lacerdaph235 ай бұрын
Rafa is humble, Freak and beatifiul
@RafaelPonte5 ай бұрын
Hehe, you're very kind, my friend! ❤
@MrDaniloko234 ай бұрын
Great content!
@RafaelPonte4 ай бұрын
Thanks 🙏🏻
@DiegoFerreiradaSilva5 ай бұрын
mandou bem, parabéns!
@RafaelPonte5 ай бұрын
Obrigado, Diego ❤️
@simongeard48243 ай бұрын
As a side note, the original example program has one further problem which wasn't discussed - if the job runs every 60 seconds, what happens if it takes more than 60 seconds to complete, giving you unintended parallel processing? I've been bitten by that one a few times...
@RafaelPonte3 ай бұрын
Thanks for the comment! 😊 In the context of the talk, this is not an issue. I mean, Spring will not allow running multiple jobs for the same task, even if it takes longer than 60 sec. But if the method is annotated with @Async then we can not say the same 😬
@simongeard48243 ай бұрын
@@RafaelPonte Fair enough... you're right that a good scheduler will avoid the problem (for sync operations, at least). My negative experiences have typically been with more naive scheduling tools...
@michaelchung8102Ай бұрын
@@RafaelPonte Does it mean the while-true loop is also fine? And how will Spring behave if the job takes slightly longer than 60 seconds? Will it let it complete the last batch process iteration?
@RafaelPonteАй бұрын
@@michaelchung8102 Spring will not stop or kill the thread running the job. Since the while-true loop has a break statement, the job will run until all the filtered rows from the table are processed, and it's ok if this execution takes more than 1 minute. After that, the Spring Scheduler will wait 1 minute before starting the same job again. Does it make sense?
@michaelchung8102Ай бұрын
@@RafaelPonte oh yes, I forget that without Async, Spring will just queue the jobs if previous ones are still running, thanks for your quick reply, and a big thanks to you as this video answers the doubts about race condition and performance concerns in distributed scheduling that I had for years. ❤️
@zickzack9875 ай бұрын
Ummm... Distribution topic starts after 27 min. Using db locks is tricky and works differently for different databases, e.g. lock escalation. Better use an app level locking. All that had not really to do a lot with jobs. Just long running tasks in a distributed system.
@RaphaelSousa-or1dl5 ай бұрын
Do you have a resource recommendation on app level locking? I'm studying the topic and it would be awesome to see it more detailed. Thanks
@RafaelPonte5 ай бұрын
Thanks for your comment ☺ Distributed systems are tricky, and database locks have worked well for over 30 years. Although some databases might differ, an exclusive row-level lock works similarly. By the way, a few RDBMS suffer from lock escalation, but not PostgreSQL (which was used in the talk's context); in addition to that, we used many approaches in the talk that mitigate the chances of lock escalation 💪🏻 Regarding application-level locking, PostgreSQL offers Advisory Locks as an excellent alternative to row-level locks. They're very light and are handled by the application side.
@gsledoux5 ай бұрын
Parabéns marajá! 😉
@RafaelPonte5 ай бұрын
Brigadão ☺️☺️
@lhsantos895 ай бұрын
What a prince 💛🔥
@RafaelPonte5 ай бұрын
Thanks, Luis ❤
@rommelcosta65485 ай бұрын
excellent lecture 💚
@RafaelPonte5 ай бұрын
Thanks, my friend!
@DevMultitask5 ай бұрын
Great job Rafael!
@RafaelPonte5 ай бұрын
Thank you ☺
@顾清l5 ай бұрын
In my understanding, `select ... limit 50 for update` would directly lock these 50 rows, instead of locking one row and processing one row at a time. But in the video, it seems to be the latter approach. Why is that?
@wukash9995 ай бұрын
He just presents it like that for a purpose of presentation. Of course it will lock all 50 rows (as long as they meet select criteria and are not locked already). Overall this is a very basic presentation, not sure what was the point of that.
@RaphaelSousa-or1dl5 ай бұрын
@@wukash999 I think the point is to introduce to more unexperienced people the possibles problems one might encounter, so you can study further on it (at least for me it worked ,since I've never thought or knew about this problems), not to make a thourough implementation guide
@RafaelPonte5 ай бұрын
Thanks for your comment ☺ As @wukash999 commented, the idea was to make it as didactic and accessible as possible so that junior and inexperienced developers could understand it. Do you think it got confused?
@RafaelPonte5 ай бұрын
@@wukash999 Thanks for your comment and helping them to understand my intention ☺ Do you think this was an introductory and basic talk? I'm afraid I have to disagree. The talk was designed to simplify the subject and make it accessible for everyone, but it's still a complex, tricky, and detailed theme.
@yonishachar18873 ай бұрын
@@wukash999 How is that a very basic presentation? How would you implement it differently?
@metrocartao5 ай бұрын
Muito bom!
@RafaelPonte5 ай бұрын
que massa que gostou 😊
@davi.mustafa5 ай бұрын
é o cara! boooraa!
@RafaelPonte5 ай бұрын
Valeu Mustafa 👊🏻
@fonfux01232 ай бұрын
Essa abordagem serve para todos os modelos de banco ou há algum diferencial entre eles por exemplo o Oracle?
@RafaelPonte2 ай бұрын
Obrigado pelo comentário! 😊 Eu discuti vários problemas e soluções na talk, e a maioria roda bem com a maioria dos bancos relacionais, mas podem sim haver nuances. De qual abordagem vc fala exatamente?
@fonfux01232 ай бұрын
bom dia Rafael eu tentei usando Oracle 12c subindo 2 instâncias no ecs mas ao executar um job que busca do banco e publica em um tópico as instâncias trazem registros repetidos! Parabéns pela live de ontem no deveficiente! Agora tb serei seu aluno lá
@RafaelPonte2 ай бұрын
@@fonfux0123 valeu! então, Oracle suporta bem o que discuti na talk. Como está o SELECT executado pela aplicação? Ele está sendo gerado FOR UPDATE ou FOR UPDATE SKIP LOCKED?
@fonfux01232 ай бұрын
@@RafaelPonte com for update skip locked! acho que tem algo a ver com os cursores do oracle como funcionam! posso estar enganado! ou entao o fato de eu estar delimitando a qtd de registros da consulta e ele so da o lock depois de obter o resulta pra cada uma das linhas
@RafaelPonte2 ай бұрын
@@fonfux0123 Entendi. Isso é verdade. No caso do SKIP LOCKED, o Oracle somente faz o locking durante o fetching do registro, e não durante a seleção (filtering) do mesmo. Mas isso normalmente acontece quando você está manipulando explicitamente cursores via PL/SQL ou alguma API de persistência. Aqui nessa outra talk sobre SKIP LOCKED focada em Oracle, eu comento essa "limitação": kzbin.info/www/bejne/bnW5d5ZtnL2Zf7M Espero que ajude!
@adyanto40434 ай бұрын
The thing i hate the most in this video - "Conluding...", i was so engaged didnt wanted him to stop.
@RafaelPonte4 ай бұрын
hahaha, thank you so much for this lovely comment 🙏🏻😍 I am thrilled after reading it!!
@rabah43065 ай бұрын
@Transactional Will this works if You have to call a mongoRepositoy and Kafka template ? All or nothing If Kafka call KO The mongo call also ?
@RafaelPonte5 ай бұрын
Thanks for your comment ☺ Although MongoDB and Kafka support some level of transactions, I don't know how @Transactional annotation would work with MongoRepositories or KafkaTemplates. It's worth reading the Spring Data docs. But it's important to be aware that you do NOT have an atomic operation (all or nothing) when your code mixes different external service calls, like PostgreSQL, Mongo, and Kafka. When you do that, you hit a common issue in distributed systems called "dual write".
@asterixcode5 ай бұрын
@@RafaelPonte I have the same use case where i need to write to mongo, kafka and also to google cloud storage bucket within the same transaction. Do you by any chance know how to solve this problem so I get a all or nothing? Or if not possible, how we would solve this problem then….
@rabah43065 ай бұрын
@@RafaelPonte obrigado :)
@MrKar185 ай бұрын
For mongo, you can spin a new session with transaction as well, manually. However for Kafka if the produced records are idempotent, you can use the mongo transaction support above to achieve the same.
@brunobrasilweb5 ай бұрын
Parabéns Rafael, Zerou game do Java.
@RafaelPonte5 ай бұрын
hahaha, valeu bruno!!!
@thiagonunes36195 ай бұрын
Nice!!
@RafaelPonte5 ай бұрын
Thanks! ❤
@eddwinpaz5 ай бұрын
Adorei a conversa, mas não sei se queria falar sobre Spring Boot ou se candidatar a político, hahaha.. brincadeira!
@RafaelPonte5 ай бұрын
Hahaha, valeu! 😊
@flavioecintia5 ай бұрын
boa ponte!!!!!
@RafaelPonte5 ай бұрын
Valeu, Flávio 😊
@gleicianylemos88245 ай бұрын
👏👏👏
@RafaelPonte5 ай бұрын
thanks!!!
@mustafaabdsh5 ай бұрын
thank you
@RafaelPonte5 ай бұрын
you're welcome! ☺
@TJ-hs1qm5 ай бұрын
Is he describing Spark 😆?
@RafaelPonte5 ай бұрын
Thanks for the comment 😊 Do you mean Apache Spark? hehe
@ereboucas5 ай бұрын
Almost made me want to work with boring techs again ;)
@andreas_bergstrom5 ай бұрын
I’m moving back to Java/JVM after 15 years in Node/JS/Python
@RafaelPonte5 ай бұрын
Boring techs are amazing! 🙌🏻
@knoppix203 ай бұрын
Ola. Todo bem
@RafaelPonte3 ай бұрын
Tudo ótimo ☺️☺️
@gabrielm68494 ай бұрын
sorry, the topic and the presentation has,without doubt, a high technical value, but the english of this guy, the accent and the way he tries-hard to emphasise almost each and every word in the sentence comes highly unnatural.. it really sounds tiring in the ear