Woohoo! It’s been three years since I started this blog, and every year I happen to write a report. If you are curious, check out the previous reports: Two years of blogging One year of blogging Page Views In these three years, I got over 1.200.000 page views and the last month was the first one to break the 70.000 views threshold.
Introduction JDBC batching has a significant impact on reducing transaction response time. As previously explained, you can enable batching for INSERT, UPDATE and DELETE statements with just one configuration property: However, this setting affects every Persistence Context, therefore every business use case inherits the same JDBC batch size. Although the hibernate.jdbc.batch_size configuration property is extremely useful, it would be great if we could customize the JDBC batch size on a per Persistence Context basis. This article demonstrates how easily you can accomplish this task.
Introduction In this article, we are going to see how we can implement a custom type using the Hibernate UserType interface. If you wonder why you’d ever want to do this, then check out this question. Our Hibernate user wants a resilient CharacterType that works with NULL or empty values. To make it even more interesting, we are going to make it work even if the underlying database column contains more than one character.
Introduction When fetching an entity, all attributes are going to be loaded as well. This is because every entity attribute is implicitly marked with the @Basic annotation whose default fetch policy is FetchType.EAGER. However, the attribute fetch strategy can be set to FetchType.LAZY, in which case the entity attribute is loaded with a secondary select statement upon being accessed for the first time. This configuration alone is not sufficient because Hibernate requires bytecode instrumentation to intercept the attribute access request and issue the secondary select statement on demand.