views:

127

answers:

1

Considering there is no @PersistenceContext available to inject the EntityManager, plus you need to manually manage Transactions, what is the best way to design such an application?

For the EntityManagerFactory/EntityManager, as far as I can see, you must have each DAO accepting an EntityManager in the costructor e.g.

public class DAOImpl implements DAO
{
    private EntityManager em;

    DAOImpl(EntityManager em){
        this.em = em;
    }

    //all CRUD operations follow
}

The first question that rises is when do you call EntityManager#close()?

Point A: The way I see it, you are better off doing this in a Filter at the end of the request cycle, which implies that you associate the EntityManager with the current thread (using ThreadLocal?)

Second question is, how and when do you inject the EntityManager?

Considering there is a ServletContextListener where we create and close the EntityManagerFactory, we could have a static method as follows

public static EntityManager createEntityManager(){
return entityManagerFactory.createEntityManager(PERSISTENT_NAME);
}

but since we want to encapsulate creating the DAO, we could use a factory e.g.

public class DAOFactory
{
    public static DAO dao(){
    //return a new DAO
    }
}

As per Point A we should use a ThreadLocal to create the DAO using the EntityManager for the current Thread.

For managing Transactions.

The best way I can think of (which mimics the JPA spec) is to create your own Transaction annotation and use reflection to inject the begin/commit/rollback operations.

You should then return a Proxy from the DAOFactory which handles the transactions

+3  A: 

I wouldn't do all that. Why try to recreate the whole JPA spec yourself? You just need to be able to use JPA without a container.

Spring can help you with this. Try it.

duffymo
I really can't see a point either but since these are the restrictions put on me, I have to find a way to implement this.
Cue