I also tried to expose a method which gives me the entitytransaction and manually flush and commit the transaction and to retrieve the vehicleFromDb in a new one. This results in the same failure.

If I have more time I will read on your blog about testing. If you have another approach to get around my problem, please let me know.

As for the other questions: the persistence context usually lives exactly as long as the transaction. When you commit the transaction, the persistence context also gets flushed. The only exception to this is that the persistence context is also flushed (but the transaction not committed) when you invoke EntityManager.find and the flush mode is set to AUTO (the default).

Unless you find a way to revive the persistence context on a new servlet request (there are ways but I have not tried them), you will always get a new one. So then it is up to the JPA provider to make sure the relations are set up correctly.

That is exactly what makes unit testing JPA code so hard. You need multiple transactions within one test to simulate this. Which makes testing within one transaction so you can easily roll back impossible. But that is something I discuss in my JPA implementation patterns blog on testing.

“Adding an OrderLine to an Order does not automatically persist it. You’ll need to also invoke the persist method on its DAO (or the EntityManager) to do that. Or you can set the cascade property of the @OneToMany annotation on the Order.orderLines property to CascadeType.PERSIST (at least) to achieve that. More on this when we discuss the EntityManager.persist method.”

I have a simple car configuration tool which saves all cars of a user. My entities look like the following:

@Entity
public class Vehicle implements Serializable {
...
    @ManyToOne
    private User owner;

    public Vehicle(User owner) {
        this.owner = owner;
        this.owner.addVehicle(this);
    }

    @PreRemove
    protected void preRemove() {
        this.owner.removeVehicle(this);
    }
...
    public User getOwner() {
        return owner;
    }
}

@Entity
public class User implements Serializable {
...
    @OneToMany(mappedBy="owner", cascade={CascadeType.PERSIST, CascadeType.REMOVE})
    private List vehicles;

    protected User() {
        vehicles = new ArrayList();
    }
...
    public List getVehicles() {
        return Collections.unmodifiableList(vehicles);
    }

    void addVehicle(Vehicle vehicle) {
        vehicles.add(vehicle);
    }

    void removeVehicle(Vehicle vehicle) {
        vehicles.remove(vehicle);
    }
}

My Unit Test looks as follows:

    @Test
    public void CreateVehicleEntity() {
        User owner = new User("vehicle_jack1","jack");
        bs.getUserFacade().create(owner);

        Vehicle vehicle = new Vehicle(owner);
        bs.getVehicleFacade().create(vehicle);

        Vehicle vehicleFromDb = f.find(vehicle.getId());
        assertTrue(vehicle.getOwner().getVehicles().contains(vehicle));
        assertTrue(vehicleFromDb.getOwner().getVehicles().contains(vehicleFromDb));
    }

This test fails on the last assert statement because the relaiton from owner to vehicle is not persisted. How can I achieve that this happens. If I call the merge operation on the User entity it works, but I don’t want the caller to know that he has to call this explicitly. If I put a cascade.PERSIST on the ManyToOne it doesn’t work either because when persisting the vehicle the user is already persisted. This makes sense because the user might want to add another car later.

If I get you right the User Entity is in a managed context and will be saved to database on commit or end of the transaction. Is that true? Can I execute a commit within the Unit test? And when does the commit usually occurs? It is a web application and the user entity will be loaded to set the values on the GUI. If the user adds another car and the callback arrives in the servlet, I save the new car like the code describes, will the relation be there when the next callback to the servlet arrives?

Thanks in advanced and by the way, I love your series on JPA patterns. Greetings from Germany, Niko

Finally, for my project, I used the mentioned pattern http://notesonjava.wordpress.com/2008/11/03/managing-the-bidirectional-relationship/ and it did it pretty well. You can even make bi-directionnal may-to-many implementation (the only difference is that you have to manage 2 lists).

Thanks again for this nice article.

I have found that in most situations exposing the details of relationships like that is simply not needed and is an example of a violation of the Principle of Least Knowledge.

It is like reaching into someones back pocket to get some cash instead of asking them to give you some cash.

reaching in, you have to know where it is and how to open the wallet, if you ask, all that is done for you and you just get the cash you asked for.

public createLine(... various details of the line...) {
  final line = new OrderLine(this, ......);
  orderLines.add(line);
}

In this way the Order Line must always belong to the Order and cannot be moved. However, exposing a moveToOrder method can handle the switching if needed and ensure it always belongs to an order.

I tend to use createXXX where ownership is needed and addXXX when only a relationship is needed if we then use Alex Snaps example then we can totally ignore the persistence aspects and instead treat the whole thing as pure objects.

To take care of an Order being deleted and wanting to clean up lines, you can of course cascade removes in this association.

In other words, the call becomes like this:

public void setOrder(NULL) {
	this.order.internalRemoveOrderLine(this);
	this.order = NULL;
}

Which is want you want. I have used this pattern in existing code *and* tried the example above before posting it, so I am pretty sure it works.

Hmmm, maybe the pattern explains itself better when the parameter name is something like newOrder.