Anghel Leonard

Moreover, your approach doesn't benefit from Hibernate implementation which handles caching. This is useful for bookmarkable URLs.

Based on your suggestion, you should add a findById(), findAll(), and so on in every repo.

Most probably you should manually add s compatible Snake YAML dependency https://mvnrepository.com/artifact/org.yaml/snakeyaml

Hi,

You mention "dynamic projection". Is this helping you:

Via DTO class:

https://github.com/AnghelLeonard/Hibernate-SpringBoot/tree/master/HibernateSpringBootDynamicProjectionClass

Via interface:

https://github.com/AnghelLeonard/Hibernate-SpringBoot/tree/master/HibernateSpringBootDynamicProjection

Correct

Thanks! Well, this is a topic of a new and comprehensive article. Nevertheless, a nice benchmark can be found here: https://interviewbubble.com/performance-comparison-of-json-libraries-jackson-vs-gson-vs-fastjson-vs-json-simple-vs-jsonp/.. Probably Jackson is the most used by Spring/SpringBoot devs. For Jakarta EE devs JSON-B is the way to go.

Consider the client trigger a request for an HTML page from the server. That request will have associated a PUSH_PROMISE frame (this is specific to the current stream ID). The client retrieves the PUSH_PROMISE frame before receiving the requested data (the HTML or other pushed resources). This frame has a header containing information useful to the client to control which resources are to be sent. Otherwise, the PUSH_PROMISE frame will send an unnecessary request for the data that will be already available. This is exactly what you point out :) Now, the client stores the pushed data in the cache and can reuse it later between different pages. For a cached or unecessary resource, the RST_STREAM frame can be rejected or the number of pushed streams can be limited. That's all! I hope it helps :)

The app from the article was deployed successfully on Payara 5.183. so very close to yours. With Spring Boot 2.0.6. Maybe, you run a new version of Spring Boot. Seems something not compatible here:

<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
<version>...</version>
</dependency>

Crystal clear! Thanks!

If yes, why not "if"?

I assume you refer to some external condition meant to determine to put the notFull in await or not. Correct?

Please explain why:

while( condition not fullfilled) {
notFull.await();
}

And, not just:

notFull.await();

What to put in place of "not fullifiled"?

When the application relies on JPA for fetching data from a database it will result in a persistent context holding the fetched snapshot (entities). This is needed by the JPA implementation to ensure data management (e.g., manage state transitions of the entities). But, this management is needed only for entities that are prone to be modified otherwise is just a performance penalty that is reflected in CPU and memory. On the other hand, fetching the read-only data as DTOs directly will avoid this overhead (the persistent context will not be populated with the snapshot and data will not be managed by JPA). Moreover, DTOs allows you to easily fetch only a subset of the properties of an entity.I hope is clear now.

Well, mainly is a trade-off between lowering network overhead (rewriteBatchedStatements) and faster execution of queries (useServerPrepStmts). I suggest you to try a benchmark and see which one fits the best for your specific case.

As a rule of thumb, before activating these features, it is better to check the latest Connector/J release notes and validate these features are safe for use together.

In this case, I suggest relying on MySQL Connector/J, which does not specify this conflict: https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-configuration-properties.html.

You can follow HikariCP example of configuration as well (notice that "useServerPrepStmts" and "rewriteBatchedStatements " are set to "true": https://github.com/brettwooldridge/HikariCP/wiki/MySQL-Configuration

I think that this can be a start point: https://blog.payara.fish/using-payara-embedded-and-payara-micro-with-maven

Good catch :) Thanks!

So, in the first example, the inferred type will be List or Set. In the second example, it will be int or String. In "uncertain" cases, the inferred type will be the broadest applicable type, which is often Object.

I've updated item 2 based on your suggestion, thanks man!

I've updated item 2 based on your suggestion, thanks man!

Thank you Charles for this valuable comment :)

So, the method returns String, not Optional, but the code uses Optional in order to decide what String to return instead of a straightforward null check. The idea is that Optional is improperly used that way, just as a null checker.

You're welcome! I'm glad that you enjoyed the article :)

done! thanks!

I have just added at the bottom of the article. Thanks for the suggestion!

I am glad that you enjoyed it! Part 2 is here.

You're welcome! :)

I'm glad that you enjoyed the article. I prepare a VP of TPM dedicated article in several days (a week). I'll let you know :)

Thanks :)

I'm glad that you found the article useful.

About OSIV: yes, I prefer to set it as "false", this is the way to go since is default "true" in Spring Boot and can cause serious performance penalties. In part two of this article, there will be an item dedicated to optimize the OSIV when you decide to use it anyway. In addition in my book, "Java Persistence Performance Illustrated Guide", there is a section dedicated to OSIV drawbacks and flow.

didn't know about it :)

Never try it :) But, I will, thanks for your suggestion

Obviously, the author of this article doesn't know enough JSF and he doesn't like JSF! Well, after he read the comments, I'm sure he learned a lot of JSF. But, instead of using his time to tell us what he knows and he likes, he loses time to tell us what he doesn't know and what he doesn't like! Pretty illogical!

What is this "article" about (and the final conclusion, which is actually the single interesting part) ? "Don’t use JSF" ...

Is this the wise man's advice to novice ?

I don't think so, because is too radical to belong to a wise man.

Is the teacher talking to students ?

Obviously, not! Some answers here comes from real JSF gurus, that cannot be considered students.

Is the professional voice that puts the things in order?

Mmmm, nope! Professionals acts as professionals! You cannot be master of multiple frameworks, so such radical opinions should remain private thoughts, or at least not so exposed.

Is just a moment of frustration ?

Well, nope again! There is no "exclamation" point there.

Is an old trick to give birth to a dispute ?

Yeap! Or ... he is the Good Samaritan that will save the world from JSF ...