Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

These are some of the patterns noticed in old codebase, which can be candidates for refactoring.

  • Usage of StaticHibernateUtil.

Throughout the codebase, there are calls to this static class for starting and committing transaction. All this class does is to provide static accessors for starting/committing transaction, getting a session associated with current thread local etc. Suggestion: get rid of StaticHibernateUtil] class altogether. And replace with HibernateUtil.getInstance(..) HibernateUtil should adopt a singleton pattern. :

public static HibernateUtil.getInstance(boolean fromContext) {
  if (fromContext)
      lookup sessionFactory from springContext. create a proxy for the session object,
      so that now all callees now participate in same transaction
  else
      the usual legacy code

}

Benefits: once we start using HibernateUtil.getInstance(boolean fromContext), we can now take informed decision to move over code to participate in spring managed transaction. Cost: why were those start/commit transactions were in code in the first place? would removing them cause any inconsistency?

  • No labels