DAO pattern in J2SE environment

Discussions

General J2EE: DAO pattern in J2SE environment

  1. DAO pattern in J2SE environment (9 messages)

    I've found some code in a J2SE application that uses the DAO design pattern as overviewed at:
    http://www.middleware-company.com/documents/DAOPattern.pdf

    The trouble is that in a J2SE environment you don't have distributed transactions (UserTransaction) so hiding the "DataSource" (in this case a JDBC connection) within the DAO leads to the inability have a transaction span multiple DAOs.

    Does this sound right? I'm thinking that the DAO should take a java.sql.Connection in it's constructor for it to use so that the caller can control the transaction.

    Threaded Messages (9)

  2. DAO pattern in J2SE environment[ Go to top ]

    Most J2EE servers manage their transaction logic using ThreadLocal variables. This eliminates the need to pass your connection explicitly. You could write a utility like the following:


    public class Transaction {
      private static final ThreadLocal localConnection = new ThreadLocal();

      public static void start() throws SQLException {
         Connection con = // Initialized connection ...
         con.setAutocommit(false);
         localConnection.set(con);
      }

      public static Connection getConnection() {
        return (Connection) localConnection.get();
      }

      public static void commit() throws SQLException {
        Connection con = getConnection();
        con.commit();
        con.close();
        localConnection.set(null);
      }

      public static void rollback() throws SQLException {
        Connection con = getConnection();
        con.rollback();
        con.close();
        localConnection.set(null);
      }
    }


    In your client:
    ---------------
    try {
      Transaction.start();
      // Invoke your DAO ...
      Transaction.commit();
    } catch (Exception ex) {
      Transaction.rollback();
    }


    In your DAO
    -----------
    Connection con = Transaction.getConnection();
    // Do not call setAutocommit(), commit(), rollback() or close()
    // Propogate any exceptions up to the client


    Of course, this example is an incredibly simplified versions of what J2EE servers do (and environments like JDO and ORM tools). It misses a lot of key issues, like connection pooling, how to manage transaction timeouts, what to do if the DAO are programmed incorrectly, how to deal with error propogation, etc. But it should give you the idea.
  3. DAO pattern in J2SE environment[ Go to top ]

    I could use thread local variable but I was thinking that was overkill.
  4. DAO pattern in J2SE environment[ Go to top ]

    If you *really* don't want to use ThreadLocal variables, then passing the connection explicitly to the DAO (probably in the constructor) would be your best bet. Personally, though, I would use ThreadLocal. The performance impact of ThreadLocal will probably be neglible.

    If you are going to take the trouble to build a transaction framework for your DAO, you may as well devote some real time to it to get it right. ThreadLocal variables can dramatically simplify the whole process overall. There are a lot of details involved in getting the transactions right, so anything that simplifies the design is a good thing.

    BTW, before you build such a system, I would suggest looking at existing ORM tools like Hibernate, Castor or some JDO software to see if they can serve as your DAO layer instead. That way you can use software where all the gory details for transaction support have already been worked out.
  5. DAO pattern in J2SE environment[ Go to top ]

    BTW, before you build such a system, I would suggest looking at existing ORM

    > tools like Hibernate, Castor or some JDO software to see if they can serve as
    > your DAO layer instead. That way you can use software where all the gory
    > details for transaction support have already been worked out.

    I'm not building such a system. It's already built! It's just that it's using DAO in a J2SE environment without any real consideration to how to handle transactions. Each DAO currently gets it's own connection and has commit(), rollback() and close() methods (with all the problems that this brings).

    I've seen Castor and am currently taking snippets of time to review newer offerings such as Hibernate, OJB and JBoss/JDO. I'm mostly fighting fires at the moment. If I had my way, this app would using a free J2EE application server like JBoss or Jonas. Unfortunately it's not my call.
  6. DAO pattern in J2SE environment[ Go to top ]

    Oh! Now I understand better. You already have the DAO, and want to retrofit them so that they are transactional.

    In that case, I would choose the ThreadLocal vs. Connection-parameter approach depending on which will have the least impact on the existing code. It would mostly depend on how the client interacts with the DAO, and how (if?) the DAO interact with each other. Either approach will work, so do whatever is easiest.
  7. DAO pattern in J2SE environment[ Go to top ]

    Thanks. That crystallises things for me.
  8. DAO pattern, JTA, J2SE[ Go to top ]

    If you want to use JTA in a J2SE environment, you could use
    JOTM

      http://jotm.objectweb.org/current/jotm/doc/howto-integrate-jotm.html

    If you want to use JTA with the DAO pattern, you should look at
    this project:

     http://daoexamples.sourceforge.net/

     http://daoexamples.sourceforge.net/xref/index.html
  9. JTA, DAO pattern[ Go to top ]

    Take a look at this code:

    http://daoexamples.sourceforge.net/xref/daoexamples/movie/MovieDAOImplJTA.html
  10. DAO pattern, JTA, J2SE[ Go to top ]

    Using JOTM is an interesting idea but it would take rather alot of work. I may as well port the entire app to an application server if going that route.