Saturday, May 26, 2007

Annoying warnings

If you are annoyed by warnings about unchecked conversions and the
@SuppressWarnings("unchecked") seems too broad (you have to annotate a whole method for just a line of code) this has an interesting suggestion. Interesting java syntax, too.

Tuesday, May 22, 2007

All about singletons

This is a little bit old but quite thorough article about singletons. It addresses all singleton issues with concurrency, classloading and serialization. However, the fourth implemention of a thread-safe singleton (Example 7) misses the lazy-loading requirement (the singleton instance is not created when first accessed but earlier at class loading). This article gives a different implementation that is both thread-safe and lazy-loaded and this explains why. See also the discussion here.

Thursday, May 17, 2007

Field access vs Property access in JPA

JPA allows for two types of access to the data of a persistent class. Field access which means that it maps the instance variables (fields) to columns in the database and Property access which means that is uses the getters to determine the property names that will be mapped to the db. What access type it will be used is decided by where you put the @Id annotation (on the id field or the getId() method).

I have developed a preference for field access mainly for two reasons. First, because I frequently define getter methods that are not property accessors e.g. a getter that does not just return the value of a field but does a calculation and returns the result. In that case (and if you use property access) you have to annotate the getter with @Transient. If you forget to do this (as I did many times) you are looking for trouble. JPA will think that the getter corresponds to a property and funny things will happen.

The second reason I prefer field access is that with property access you have to define getter methods for every field just for use by JPA even if your code will never call them.

Until now I haven't find any argument in favor of property access but I would like to hear if anybody has.

Wednesday, May 2, 2007

Transaction management and JPA

My current project is a web application with Struts in the web tier, a stateless session ejb (EJB3) in the middle tier and various entity pojos (JPA) that model the data. The application server is Jboss 4.2.0.CR2 that uses Hibernate as the persistence provider.

In this configuration with container-managed transactions, the transaction boundary is the ejb method call. Struts action classes make calls to the session ejb methods in order to retrieve data for display in various jsps. The problem is that after the ejb method returns, the transaction is over, the persistence context has ended and the pojos returned are detached. If the jsp that displays the data tries to access any lazily loaded associations an exception occurs. One solution might be to load every association eagerly but this could become very expensive in terms of performance and is definitely not scalable. Another approach might be to write different ejb methods that initialize the associations needed in different views but this will make the API between the web and middle tier very complicated.

What I finally did was borrowed by Hibernate. Hibernate suggests the use of the HibenateUtil class that manages transactions and is called usually in an HttpFilter. In this configuration the transaction boundary is the http request. In my case, I extended the Struts RequestProcessor and overridden the process method.


public class MyRequestProcessor extends RequestProcessor {
    private static Logger logger = Logger.getLogger(MyRequestProcessor.class);
  
    private static final ThreadLocal<UserTransaction> threadTransaction = new ThreadLocal<UserTransaction>();

    @Override
    public void process(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
        UserTransaction utx = null;
        try {
            utx = threadTransaction.get();
            if (utx == null) {
                Context ctx = new InitialContext();
                UserTransaction utx = (UserTransaction) ctx.lookup("UserTransaction");
                threadTransaction.set(utx);
                utx.begin();
            }
            super.process(request, response);
            utx.commit();
        }
        catch (Exception e){
            try {
                if (utx != null)
                    utx.rollback();
            }
            catch (Exception e1) {
                logger.error("Cannot rollback transaction", e1);
            }
            throw new ServletException(e);
        }   
        finally {
            threadTransaction.remove();
        }
    }
}

At the beginning of the processing the UserTransaction is initialized and after the processing it is committed. If an exception happens it is rolled back. By using this approach we make sure that the transaction and the persistence context are active after the ejb method returns and during the action and jsp execution thus enabling us to traverse association from inside the jsps. This approach has a problem though. If a forward is done from a struts action to another the request processor is called again in the same thread and thus the transaction will be committed twice (once per request processor call) resulting in an exception in the second attempt to commit. This can be resolved by use of some flag that marks the outermost call, so that we do the commit only there.

Another approach would be the use of an http filter that begins and commits the transaction thus moving the transaction boundaries at the http request.

All the above approaches do not make any reference to Hibernate classes so the implementation is persistence provider agnostic.