JPA 2.1 Entity Graph - Part 2: Define lazy/eager loading at runtime

This is my second post on Entity Graphs, one of the features introduced with JPA 2.1. The first post described the usage of named entity graphs. These can be used to define a graph of entities and/or attributes at compile time that shall be fetched with a find or query method. Dynamic entity graphs do to the same but in a dynamic way. This means you can use the EntityGraph API to define your entity graph at runtime.
If you have missed the first post and want to read how to define a named entity graph or how lazy loading issues were solved with JPA 2.0, check this post: JPA 2.1 Entity Graph - Part 1: Named entity graphs

Conference Report: JUG Saxony Day 2014

Last friday (2014-04-04) I visited the JUG Saxony Day 2014 in Dresden, Germany. It was the first event organized by the JUG Saxony and to make it short, it was great! The event was well organized and had lots of interesting talks.
But let's get into more details ...

The conference offered 4 tracks with 5 sessions each:

1. Software development process
2. Java technology
3. Research
4. Java mobile and enterprise applications with Java

So I had to make a hard decision to select 5 tracks for the day...

JPA 2.1 Entity Graph - Part 1: Named entity graphs

Lazy loading was often an issue with JPA 2.0. You have to define at the entity if you want to use FetchType.LAZY (default) or FetchType.EAGER to load the relation and this mode is always used. FetchType.EAGER is only used if we want to always load the relation. FetchType.LAZY is used in almost all of the cases to get a well performing and scalable application.
But this is not without drawbacks. If you have to use an element of the relation, you need to make sure, that the relation gets initialized within the transaction that load the entity from the database. This can be done by using a specific query that reads the entity and the required relations from the database. But this will result in use case specific queries. Another option is to access the relation within your business code which will result in an additional query for each relation. Both approaches are far from perfect.

JPA 2.1 entity graphs are a better solution for it. The definition of an entity graph is independent of the query and defines which attributes to fetch from the database. An entity graph can be used as a fetch or a load graph. If a fetch graph is used, only the attributes specified by the entity graph will be treated as FetchType.EAGER. All other attributes will be lazy. If a load graph is used, all attributes that are not specified by the entity graph will keep their default fetch type.

Lets have a look how to define and use an entity graph.

SSL encrypted EJB calls with JBoss AS 7

Encrypting the communication between client and server provides improved security and privacy protection for your system. This can be an important requirement by the customer, especially if client or server need to work in an unprotected network.

This article shows you how to setup SSL encrypted EJB calls in JBoss AS 7.

Generate your JAXB classes in a second with xjc

Since JAXB is part of the JDK, it is one of the most often used frameworks to process XML documents. It provides a comfortable way to retrieve and store data from XML documents to Java classes. As nearly every Java developer has already used JAXB, I will not explain the different JAXB annotations. Instead I will focus on a little command line tool called xjc and show you how to generate your binding classes based on an existing XSD schema description.

JPA 2.1 Attribute Converter - The better way to persist enums

Persisting enums with JPA 2.0 is possible, but there is no nice way to do it. Using the @Enumerated annotation, you can use EnumType.ORDINAL or EnumType.STRING to map the enum value to its database representation. But both options have their drawbacks. The ordinal of an Enum depends on the ordering of its values and can create problems, if we need to add new ones. The String representation of an Enum is often quite verbose and renaming a value will break the database mapping. These drawbacks can be avoided by using an Attribute Converter.

Criteria Update/Delete - The easy way to implement bulk operations with JPA2.1

With JPA2.1 the Criteria API was extended by CriteriaUpdate and CriteriaDelete. The two classes can be used to implement bulk update and delete operations using the Criteria API.