Sunday, June 15, 2014

Serialization Proxy Pattern example

There are books, which change your life immensely. One of such books is "Effective Java" by Joshua Bloch. Below you may find small experiment, which was inspired by Chapter 11 of this book - "Serialization".

Suppose that we have a class designed for inheritance, which is not Serializable itself, and has no parameterless constructor, like in this example:
public class CumbersomePoint {

    private String name;

    private double x;

    private double y;

    protected CumbersomePoint(double x, double y, String name) {
        this.x = x;
        this.y = y;
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public double getX() {
        return x;
    }

    public double getY() {
        return y;
    }

    ...
}
Now when we extend this class, for example in following way:
public class ConvenientPoint extends CumbersomePoint implements Serializable {

    public ConvenientPoint(double x, double y, String name) {
        super(x, y, name);
    }

    ...
}
and try to serialize and then deserialize any of ConvenientPoint instances, we'll quickly encounter beautiful InvalidClassException, complaining that there is no valid constructor. Situation looks kinda hopeless, until you apply technique known as Serialization Proxy Pattern.

We will start by adding to the ConvenientPoint class following inner class:
private static class SerializationProxy implements Serializable {

        private String name;

        private double x;

        private double y;

        public SerializationProxy(ConvenientPoint point) {
            this.name = point.getName();
            this.x = point.getX();
            this.y = point.getY();
        }

        private Object readResolve() {
            return new ConvenientPoint(x, y, name);
        }

    }
The SerializationProxy class will represent the logical state of enclosing class instance. We will have to add also following method to ConvenientPoint class:
    private Object writeReplace() {
        return new SerializationProxy(this);
    }

Now when the ConvenientPoint instance will be serialized, it will nominate its replacement, thanks to writeReplace method - SerializationProxy instance will be serialized instead of ConvenientPoint.

From the other side, when SerializationProxy will be deserialized, readResolve method usage will nominate its replacement, being ConvenientPoint instance.

As you see, we've made ConvenientPoint serializable, regardless of missing parameterless constructor of non-serializable parent class.

One more remark, at the end of this post - if you want to protect against breaking class invariants, enforced by the constructor, you may add following method to class using Serialization Proxy Pattern (ConvenientPoint in our example): 
    private void readObject(ObjectInputStream stream) throws InvalidObjectException {
        throw new InvalidObjectException("Use Serialization Proxy instead.");
    }
It will prevent deserialization of the enclosing class.

Sunday, May 4, 2014

@OneToOne with shared primary key, revisited :)

Long time ago, I wrote a post @OneToOne with shared primary key. Today I would like to return to this problem, with solution based on @MapsId annotation introduced in JPA 2.0

Again we have two entities: Primus and Secundus. Both entities have primary key using Long Java type. They are related 1-1, and Secundus should use the same primary key as Primus.
3 Years after my initial post they will look slightly different ;)
@Entity
@Table(name = "PRIMUS")
public class Primus {

    public static Primus newInstance() {
        Primus primus = new Primus();
        primus.secundus = new Secundus(primus);
        return primus;
    }

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @OneToOne(cascade = CascadeType.ALL, mappedBy = "primus")
    private Secundus secundus;

    Primus() {
        super();
    }
    ...

}
Not much changed here, ;). Really important changes were made on the Secundus:
@Entity
@Table(name = "SECUNDUS")
public class Secundus {

    @Id
    private Long id;

    @JoinColumn(name = "ID")
    @OneToOne
    @MapsId
    private Primus primus;

    Secundus() {
        super();
    }

    public Secundus(Primus primus) {
        this();
        this.primus = primus;
    }
As you see, the @PrimaryKeyJoinColumn annotation is replaced with two annotations: @MapsId, which defines that Secundus identifier will be determined by Primus identifier, and @JoinColumn, specifying which column in SECUNDUS table will be used for joining. 

Nothing more is needed :) - JPA Provider should automatically ask Primus for its identifier, when persisting Secundus, as long as you take care of correct entities correlation, like in newInstance method of Primus.

Long live JPA 2.0+ ;) :) 

Saturday, May 11, 2013

JPA - Querydsl Projections

In my last post: JPA - Basic Projections - I've mentioned about two basic possibilities of building JPA Projections. This post brings you more examples, this time based on Querydsl framework. Note, that I'm referring Querydsl version 3.1.1 here.

Reinvented constructor expressions


Take a look at the following code:

The above Querydsl construction means: create new JPQL query [1] [2], using employee as the data source, order the data using employee name [3], and return the list of EmployeeNameProjection, built using the 2-arg constructor called with employee ID and name [4].  This is very similar to the constructor expressions example from my previous post (JPA - Basic Projections), and leads to the following SQL query:

select EMPLOYEE_ID, EMPLOYEE_NAME from EMPLOYEE order by EMPLOYEE_NAME asc

As you see above, the main advantage comparing to the JPA constructor expressions is using Java class, instead of its name hard-coded in JPQL query.

Even more reinvented constructor expressions


Querydsl documentation [4] describes another way of using constructor expressions, requiring @QueryProjection annotation and Query Type [1] usage for projection, see example below. Let's start with the projection class modification - note that I added @QueryProjection annotation on the class constructor.

Now we may use modified projection class (and corresponding Query Type [1] ) in following way:

Which leads to SQL query:

select EMPLOYEE_ID, EMPLOYEE_NAME from EMPLOYEE order by EMPLOYEE_NAME asc

In fact, when you take a closer look at the Query Type [1] generated for EmployeeNameProjection (QEmployeeNameProjection), you will see it is some kind of "shortcut" for creating constructor expression the way described in first section of this post.

Mapping projection


Querydsl provides another way of building projections, using factories based on MappingProjection.


The above class is a simple factory creating EmployeeNameProjection instances using employee ID and name. Note that the factory constructor defines which employee properties will be used for building the projection, and map method defines how the instances will be created.

Below you may find an example of using the factory:

As you see, the one and only difference here, comparing to constructor expression examples, is the list method call.

Above example leads again to the very simple SQL query:

select EMPLOYEE_ID, EMPLOYEE_NAME from EMPLOYEE order by EMPLOYEE_NAME asc

Building projections this way is much more powerful, and doesn't require existence of n-arg projection constructor.

QBean based projection (JavaBeans strike again)


There is at least one more possibility of creating projection with Querydsl - QBean based - in this case we build the result list using:

... .list(Projections.bean(EmployeeNameProjection.class, employee.employeeId, employee.name))

This way requires EmployeeNameProjection class to follow JavaBean conventions, which is not always desired in application. Use it if you want, but you have been warned ;)

Few links for the dessert

  1. Using Query Types
  2. Querying
  3. Ordering
  4. Constructor projections


Follow-ups:


This article has been republished on Java Code Geeks (05/14/2013), and on Dzone's Javalobby (05/15/2013).

Saturday, May 4, 2013

JPA - Basic Projections

In my last post: JPA - Should I become a laziness extremist? - I mentioned about the possibilities of improving JPA usage - one of them is using Projections.

Projection is a subset of entities' properties. It can be represented as dedicated class (or classes), and mapped either as the database view based entity, or using constructor expressions [1][2]. The clue of this solution is having very limited entities tree (or no tree at all, as in my example) comparing to original entity (Employee). We need to display employee name, thus we build the projection having employee name and ID only. As you will see below, using projections leads to single SQL query, instead of bunch of SQL queries (see example in JPA - Should I become a laziness extremist?)

Database view based entities


What we need in this case is simple JPA entity, mapped to any database view (or table if desired properties are in one table).

Now we can run JPQL query:

select employee from ViewBasedEmployeeNameProjection employee order by employee.name

which in turn will execute one single SQL query:

select EMPLOYEE_ID, EMPLOYEE_NAME from EMPLOYEE order by EMPLOYEE_NAME

Using this method you have to remember that you can choose anything for the projection ID, as long as it uniquely identifies each projection. 

Constructor expressions


What we need in this case is a class representing the projection with constructor having parameters corresponding to all properties in the projection.
 
Now we can run JPQL query:

select new com.blogspot.vardlokkur.domain.EmployeeNameProjection(employee.employeeId, employee.name) from Employee employee order by employee.name

which in turn will execute one single SQL query:

select EMPLOYEE_ID, EMPLOYEE_NAME from EMPLOYEE order by EMPLOYEE_NAME

This method has some disadvantages:
  • adding new projection properties increases number of constructor parameters
  • projection class name is included in JPQL query, which may lead to refactoring problems
Second disadvantage can be solved with Querydsl, which also gives you few more possibilities of building projections, but that will be subject of my next post :) 

To be continued ...

Few links for the dessert

  1. JPQL Constructor Expressions
  2. Result Classes (Constructor Expressions)


Follow-ups:


This article has been republished on Dzone's Javalobby (05/06/2013).

Saturday, April 27, 2013

JPA - Should I become a laziness extremist?

When you spoke with the Developers about mapping objects to relational databases, they very often complain about poor JPA performance, unpredictable behavior of JPA Providers, etc. Usually at some point of the conversation you will hear: "Let's drop this technology at all, we've seen something much better on the conference last month. We will use it in our projects instead of JPA and develop them happily ever after." - Sounds familiar? :)

It's nothing wrong in learning new technologies, in fact you should do it constantly, to improve your skills and knowledge, but when you have problems with one of them, will you choose an easy path to another technology, or ask yourself: "Am I using it in a right way?"

Let's look at the JPA usage example. Suppose that we have simple database, mapped to the entities:


and we have to display all employee names, regardless their employer (and department). Nothing easier ;) - simple JPQL query will do that:

select employee from Employee employee order by employee.name

Many developers finish at this point, and celebrate with Friends another successful JPQL query in their life ;), but some of us have this strange feeling, that something creepy is lurking beneath the shiny surface. SQL queries produced by the JPA provider (ex. Hibernate) will reveal the truth: 
select [...]  from EMPLOYEE employee0_ order by employee0_.EMPLOYEE_NAME

Nothing special, so far :), but here comes the naked truth:
select [...] from DEPARTMENT department0_ left outer join EMPLOYER employer1_ on department0_.EMPLOYER_ID=employer1_.EMPLOYER_ID where department0_.DEPARTMENT_ID=?
select [...] from EMPLOYER employer0_ where employer0_.EMPLOYER_ID=?
select [...] from DEPARTMENT department0_ left outer join EMPLOYER employer1_ on department0_.EMPLOYER_ID=employer1_.EMPLOYER_ID where department0_.DEPARTMENT_ID=?
select [...] from DEPARTMENT department0_ left outer join EMPLOYER employer1_ on department0_.EMPLOYER_ID=employer1_.EMPLOYER_ID where department0_.DEPARTMENT_ID=?
select [...] from DEPARTMENT department0_ left outer join EMPLOYER employer1_ on department0_.EMPLOYER_ID=employer1_.EMPLOYER_ID where department0_.DEPARTMENT_ID=?
What the heck?! What are these queries for?! - Well the reason lies in default fetch attribute values for @ManyToOne annotations, which is EAGER. My database holds 2 Employers, one of them has 4 Departments, while second one hasn't any. When the Employee is loaded, JPA provider loads by default all EAGER associations (in our case both Department, and Employer), thus we have the additional queries. As you see above the JPA provider is clever enough to load both Employer and Department at once, when it is possible.

You've just found magical JPQL query fetching all the database content at once :). Does this situation remind you something in the past? ;)

What can we do about it? - My Friend, all you need is a laziness :) - Don't use EAGER unless it is REALLY needed (and remember that @ManyToOne and @OneToOne annotations use it by default).

You may call me a lunatic, or laziness extremist at this point :) and ask: Have you ever encountered LazyInitializationException, Bro!? Have you heard of all the mess with lazy loading problems!? Performance degradation, etc. ... Of course I did :), but don't you think that if we are getting in such troubles with JPA, maybe we use it in a wrong way?!

What we do usually in Web Applications is presenting or editing some data on UI, and usually it is only small subset of specific entities' properties. Doing it requires fetching the entities tree from the database - without batting an eye, we ask Entity Manager: give me all Employees, sorted by name, with all related entities, and then complain on degraded performance!

We don't care what we fetch from the database, because Entity Manager will do the donkey work for us. We get LazyInitializationException, so what! We will use Open Entity Manager in View pattern, and silence this stupid exception!

Give a me a break! Don't you think it's a dead end? :) - It's about time to change something :) There are sophisticated methods which you can use in your projects, like CQRS for example, along with possibilities already existing in JPA, which can help you change the bad manners described by me in this post.

To be continued ...

Few links for the dessert:




Follow-ups:


This article has been republished on Java Code Geeks (05/01/2013), and on Dzone's Javalobby (05/01/2013).