Organize Your Named JPQL Queries

Named queries have some nice properties. They are precompiled and therefore faster than their “normal” counterparts, encourage to use named parameters, make your code easier to read and avoid messing up your code with string concatenated queries. A nice addon is, that named queries are validated during the creation of the persistence unit. If you have a unit test (see unit test db schema and named queries), checking whether the entities represent a valid DB Schema, the named queries are validated, too. So, there will be syntactical as well as some static analysis (e.g. “exist all referenced entities?”) during the test phase, before your application is even packaged.
Read More

EAGER Fetch of Multiple Associations

Associations are fetched lazily by default. You may change this behavior by setting the parameter fetch=FetchType.EAGER of the annotation @OneToMany for example. This has the disadvantage, that the association is eagerly fetched each time the respective entity is retrieved from the underlying database. This leads to the so called cartesian product read issue since the respective association is retrieved with the query of the owning entity via LEFT OUTER JOIN (see JPQL and joins). So, a lot of redundant data might be retrieved from the database, since the OR-Mapper has no interception point where he can prevent to retrieve data cached already. Another way is to overwrite the lazy fetch type in a jpql query (see override fetch type). So the cartesian product read issue does still exist, but you can control when to eagerly fetch an assoctiation and when not.
Read More

Ordering Collections with JPA

Often there is the need to sort an entity or a collection, e.g. If you have a list of line items in a bill and do not want that the order may change or is semantically wrong. Unfortunately, using a java.util.List will not suffice, since the DB has not to retain the order of the list. You might recognize this only after a long time, since some RDBMS will return the rows by insertion order. There are different ways to introduce an ordering with JPA (see Java Persistence: Ordering).
Read More

Override fetch type in JPQL Queries

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

Multiple one phase resources in jBoss-5.1.0.GA

In jBoss-5.0.1.GA there was the configuration file ${JBOSS_HOME}/${SERVER_CONFIG}/conf/jbossjta-properties.xml. In order to enable distributed transactions for multiple local resources (non-XA) the following option had to be inserted into this file:

<property name="com.arjuna.ats.jta.allowMultipleLastResources" value="true"/>

In jBoss-5.1.0.GA this config file has been replaced by ${JBOSS_HOME}/${SERVER_CONFIG}/conf/jbossts-properties.xml. So you have to add the same line into the xml-element with name properties and attributes depends with value “arjuna” and name with value “jta”:

<properties  depends="arjuna" name="jta">
    <property name="com.arjuna.ats.jta.allowMultipleLastResources" value="true"/>
    <!-- ... -->
</properties>