0 Replies Latest reply on Jun 9, 2008 8:40 PM by Kevin Duncliffe

    Clustering + Spring + Hibernate without EJBs -- possible?

    Kevin Duncliffe Newbie

      Is it possible to use clustering with JBoss AS and JBoss Cache with Hibernate and Spring, but without using EJBs (i.e. without using the EntityManager)? We have heard doubts about JBoss' ability to do this -- that we would be forced to use EJBs and/or JBoss' Hibernate service to take advantage of JBoss Cache's clustering capabilities. But I don't see why this should be.

      We are deploying everything, including Hibernate, in a single WAR file. Thus we want to run our application on JBoss almost as if we were running it on pure Tomcat, using JBoss only for JBoss Cache and the JTA transaction manager it requires. We don't want to incur the considerable expense of migrating to EJB 3 (at least not right now).

      Our Java application uses Hibernate POJOs and Spring's declarative transaction management, similar to what Rod Johnson outlined in "J2EE Development without EJBs" back in 2004. We have been running this on Tomcat 6. We now want to run this app in a clustered environment, and we have been exploring options on Tomcat (e.g. Terracotta) but have run into problems and are keeping our options open. Enter JBoss.

      Can we continue to use the Hibernate we have packaged in our WAR, or will we be forced to use JBoss' Hibernate service? And if so, is that even an option with our EJB-free architecture?

      Also, we are using Spring's AnnotationTransactionAttributeSource transactionInterceptor -- are others using Spring's JtaTransactionManager as the transactionManager for declarative transactions? (Presumably JBoss Cache would use JTA by default in any event.)

      Of course we can just fire it up and see what happens, and likely we will, but even if it seems to be working, it would be good to have some confirmation from the community that others have had success with this configuration. If we're doing something fundamentally wrong I'd like to know up front, rather than find out through some subtle yet horrible error in production.

      Thanx

      Kevin