Executing a getter — representing a one-to-many or many-to-many association — on an entity causes one or n (with n entries in the collection) database calls, depending on the fetching strategy (see fetch strategies). This is a nasty little detail that may cause performance bottlenecks. Changing the fetch type (lazy/eager) may not be appropriate, since an association is generally used in more than one context, so there may be contradictory concerns. Generally spoken, an eager fetching is only in rare occasions a good idea on one-to-many or many-to-many associations, since this leads to the cartesian product problem (simply put, you have to read [nearly] the hole db in order to get one entity). Fortunately there is another solution that enables overriding a lazy fetch type in a dedicated JPQL-Query. This may entail a hole bunch of JPQL queries you will have to write (not more queries to execute on the db!!!), since you want to eagerly fetch an association in one situation but not in another.
Read More
Category: Java
OR-Mapper and the ‘many queries’ problem
Applications using an OR-Mapper like Hibernate or OpenJPA are reckoned as to be slow. This observation is true, since there is an overhead compared to using hand-crafted and optimized SQL-Queries and Database structure. But the overhead has not to be as big as it is often observed in applications with entities. There is a lot of potential optimizing such a system. Unfortunately you won’t be able to circumvent quarelling with the underlying database, although a persistence layer is all about abstraction. Not bringing into mind what happens in your persistence layer will lead to really bad performance. Read More
Unnecessary Code Detector
Recently I found a nice eclipse plugin for finding dead code. The standard eclipse check finds unused private fields and methods, only. You may use STRG+SHIFT+G for finding references to a public class or method in advance. But this approach is limited to search for methods/classes without references one by one, which is very time consuming. The UCDetector starts a search for methods and classses without any references to it in all projects in the current workspace respecting inheritance and presents the results in the ‘Problems’ view. Read More
Fetch strategy subselect for hibernate
The standard fetch strategy for collections in hibernate is lazy select fetching (hibernate performance). So if you retrieve some entities (for example via a query or a collection association) with a lazy collection association, subsequent calls to this lazy association will be retrieved one by one in further requests, for example. This is called the N+1-query problem, since there is one query for retrieving the entities itself and N additional queries for the lazy association. You can reduce the overhead by setting the hibernate.default_batch_fetch_size for your persistence unit in the persistence.xml. This reduces the problem to an N/batch_size +1-query problem. You can tell hibernate to use only 1+1-queries, if you set the fetch strategy to subselect fetching. This way, all entities in the association collections of the entities are retrieved in one query as soon as one of the associations is accessed. This will be helpfull only, if you do not pick one of the objects and retrieve the association, but iterate through your results and access the association of each of them. It is even contra productive otherwise. Read More
Interface with self-referencing generic type
The Comparable interface has a generic type parameter, which is used for self-referencing in subclasses (I don’t know any other use for it) :
public interface Comparable<E> {
public int compareTo(E other);
}
public class ComparableInteger implements Comparable<ComparableInteger> {
private int val;
public void compareTo(ComparableInteger other) {
return val > other ? 1 : (val == other ? 0 : -1);
}
But what if you need to access methods of the interface on the generic type parameter? Then you can do a recursive declaration of the type parameter. Read More
instanceof on Class objects
If you need to access the metadata of a class or be a bit less type safe than Java is by itself, you will have to get involved with the Java Reflection API. At that the question may arise, how to check whether one class object is the super class of another. If you are working with objects, you may use the java keyword instanceof. But this won’t work as expected for class objects, since all class objects are instances of Class<?> . So Class<?> owns the method cls1.isAssignableFrom(cls2), checking whether cls1 is a super class/interface or the same as cls2. So it works just like instanceof on objects, but the order of the parameters is switched.
Bug in JDK Javadoc for class java.util.regex.Pattern
The Javadoc for class java.util.regex.Pattern contains a bug. It says that a back reference (Pattern (Java Platform SE 6)) to a capturing group is depicted by \n whereas n denotes the number of the capturing group. Unfortunately this won’t work. Use $n instead.
Read More