Hibernate 3.2 + EntityManager + WebSphere 6.1 /CMT works???

amunrah · **Joined:** Wed Jan 31, 2007 5:02 am **Posts:** 6

Hibernate version: 3.2.1 GA, EntityManager

Application Server: Websphere Version 6.1, CMT

Database: Oracle 10g

IDE: IBM Application Server Toolkit (AST)

J2EE-Clients: IBM/AST universial test client (browser plugin)
IBM-Application-Client (Gui-Swing – client)

Using Stateless Session bean (EJB 2.1) /CMT with Hibernate’s EntityManager

Hibernate Configuration

Code:

   <persistence-unit name="TestUnit" transaction-type="JTA"> 
      <provider>org.hibernate.ejb.HibernatePersistence</provider> 
      <jta-data-source>jdbc/MyDataSource</jta-data-source> 
      <properties> 
         <property name="hibernate.archive.autodetection" value="class, hbm"/> 
          
           <property name="hibernate.dialect" value="org.hibernate.dialect.OracleDialect" /> 
           <property name="hibernate.show_sql" value="true"/> 
           <property name="hibernate.session_factory_name" value="MyProject/SessionFactory"/> 
           <property name="hibernate.transaction.factory_class" value="org.hibernate.transaction.CMTTransactionFactory"/> 

           <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.MyWebSphereExtendedJTATransactionLookup"/> 
           
      </properties> 
   </persistence-unit>

Hibernate helper class

Code:

    
public class JpaUtil { 


private static Map<String, EntityManagerFactory> factories = new HashMap<String, EntityManagerFactory>(); 

    /** 
     * Returns the Entity manager to use. 
     * 
     * @return Configuration 
     */ 
    public static EntityManager getEntityManager(String persistenceUnit) { 
       return getEntityManager(persistenceUnit, new HashMap()); 
    } 
    
    public static EntityManager getEntityManager(String persistenceUnit, Map overwrite) { 
       EntityManagerFactory emf = factories.get(persistenceUnit); 
       if (emf == null) { 
          emf = Persistence.createEntityManagerFactory(persistenceUnit, overwrite); 
          factories.put(persistenceUnit, emf); 
       } 
      EntityManager manager = emf.createEntityManager(); 
      manager.setFlushMode(FlushModeType.AUTO); 

        return manager; 
    }

Problem(s)

Hi all,

1)
general

has anyone deployed successfully EJB JPA/EntityManager with Hibernate 3.2.1 applications in WebSphere 6.1 (CMT) yet ?!! I found some topics concerning this subject in the hibernate groups but unfortunately without deep explanations.

I'am relatively new to hibernate/JPA and WebSphere but have to migrate a time critical project with EM/JPA-hibernate from JBoss to WebSphere 6.1 / CMT.
I have problems to find out the right configuration properties for persistence.xml and so on. Could anyone give me some short configuration / programming hints to run under above mentioned constellation ??
Or can someone offer me some contacts to customers which are using Hibernate EM successfully on Websphere 6.1

Especially handling of transaction demarcations and (auto) flushing seems to be problematic.
At the top you can see my persistence.xml and an adapted HibernateUtil (JpaUtil) class to get the EntityManager.

2)
configuration

a)
You find my favorite persistence.xml in the intro of this text.
Is this a right one to handle CMT under WebSphere’s EJB2.1 session beans ?? (MyWebSphereExtendedJTATransactionLookup differs from WebSphereExtendedJTATransactionLookup in little detail to avoid UnsupportedOperationExceptions)

I suppose not for a short time simply because:

Auto-flushing before leaving the transaction dos’nt work (manager.flush() does it) and i got hibernate warnings in my logfiles like this:

hibernate.transaction.factory_class is dangerous, this might break the EJB3 specification implementation

org.hibernate.ejb.AbstractEntityManagerImpl joinTransaction - Cannot join transaction, not a JoinableCMTTransaction

This is so, because hibernate can’t get a JoinableCMTTransaction but gets a “normal” instead.
Flushing may be resolved by the Version 3.2.2, I found some notes about it.
!!! But this is the only one configuiration I can try out some selects without any exception thrown !!!

Are there any other issues how to configure EM hibernate 3.2 with CMT WAS 6.1 ??!!!

b)
Commenting the "hibernate.transaction.factory_class" avoids the warning mentioned under a).
But with this property set I got an exception for the simplest test case(s) (and all others): transaction-attribute = REQUIRED, simple hibernate-select using the IBM application client launcher:

Code:

 javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name comp/websphere not found in context "java:".]

The whole listing one can find on the bottom of this posting.
This looks like a lost binding or looking for a binding in a non-appropriate point.

c)
Additional I found a different behaviour in how calling the test use case:
Sometimes all works fine under the so called "universal test client" of IBM's AST - IDE testing method by method.

But if one wants to call the services by an application client (launcher) i got the described above "javax.naming.NameNotFoundException" raised by the WebSphereExtendedJTATransactionLookup" class (see below).

3)
EntityManager

I use the JpaUtil class above to create the EntityManager to use.

a)
I found hints in the community like this:

This seem two requirements not working together. Only the Container knows when the work has finished ?! Anyone solved that problem ?
In real EJB 3.0 environments the injected manager never have to be closed by the application code. But I have not such (WebSphere).

b)
Furthermore I debugged the EM creation and found usage of sessionfactory.openSession(). On the other side I found hints in the community to use sessionfactory.getCurrentSession() under CMT for work without EM. ? ?

c)
If I call the JpaUtil twice in the same Thread without leaving the session bean code and transaction scope I expected to get two instances of the EM mapping to the same PersistenceContext (Session). But this is’nt so! This test case raises an assertion:

Code:

/*
* transaction-attribute set to REQUIRED
*/
public void myRemoteTestMethod() {
      
    A a = new A(); // with id as pk
    …
    JpaUtil.getEntityManager("TestUnit").persist(a);
    AssertNotNull(findA(a));
}

private A findA(A a) {
    return JpaUtil.getEntityManager("TestUnit").find(A.class, a.getId());
}

d)
Are there other EntityManager[Factory] implementations I have to use than the standard ones?
(I saw this under Jboss: ManagedEntityManagerFactory | TransactionScopedEntityManager | InjectedEntityManagerFactory )

4)
Datasource binding

This binding is described in the persistence.xml:

<jta-data-source>jdbc/MyDataSource</jta-data-source>

Have I to define DataSource references to my EJB2.1 SessionBeans to get hibernate work together with WebSphere CMT ???

It seems that I’am trying to train a elephant !!

Thanks a lot,
Tom

==================================

Here the Exception.

Code:

javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name comp/websphere not found in context "java:".]
   at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
   at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
   at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
   at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
   at javax.naming.InitialContext.lookup(InitialContext.java:363)
   at org.hibernate.transaction.MyWebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.<init>(MyWebSphereExtendedJTATransactionLookup.java:118)
   at org.hibernate.transaction.MyWebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.<init>(MyWebSphereExtendedJTATransactionLookup.java:115)
   at org.hibernate.transaction.MyWebSphereExtendedJTATransactionLookup$TransactionManagerAdapter.getTransaction(MyWebSphereExtendedJTATransactionLookup.java:85)
   at org.hibernate.transaction.CMTTransaction.getTransaction(CMTTransaction.java:91)
   at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:489)
   at org.hibernate.transaction.MyWebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter$1.invoke(MyWebSphereExtendedJTATransactionLookup.java:139)
   at $Proxy15.beforeCompletion(Unknown Source)
   at com.ibm.ws.jtaextensions.SynchronizationCallbackWrapper.beforeCompletion(SynchronizationCallbackWrapper.java:65)
   at com.ibm.ws.Transaction.JTA.RegisteredSyncs.distributeBefore(RegisteredSyncs.java:240)
   at com.ibm.ws.Transaction.JTA.TransactionImpl.prePrepare(TransactionImpl.java:2373)
   at com.ibm.ws.Transaction.JTA.TransactionImpl.stage1CommitProcessing(TransactionImpl.java:1606)
   at com.ibm.ws.Transaction.JTA.TransactionImpl.processCommit(TransactionImpl.java:1577)
   at com.ibm.ws.Transaction.JTA.TransactionImpl.commit(TransactionImpl.java:1512)
   at com.ibm.ws.Transaction.JTA.TranManagerImpl.commit(TranManagerImpl.java:237)
   at com.ibm.ws.Transaction.JTA.TranManagerSet.commit(TranManagerSet.java:162)
   at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:756)
   at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:181)
   at com.ibm.ejs.csi.TransactionControlImpl.postInvoke(TransactionControlImpl.java:581)
   at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3893)
   at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3715)
   at test.EJSRemoteStatelessService1_cf5b67a9.simpleSelectTest(EJSRemoteStatelessService1_cf5b67a9.java:382)
   at test._EJSRemoteStatelessService1_cf5b67a9_Tie.simpleSelectTest(_EJSRemoteStatelessService1_cf5b67a9_Tie.java:403)
   at test._EJSRemoteStatelessService1_cf5b67a9_Tie._invoke(_EJSRemoteStatelessService1_cf5b67a9_Tie.java:114)
   at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:613)
   at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:466)
   at com.ibm.rmi.iiop.ORB.process(ORB.java:503)
   at com.ibm.CORBA.iiop.ORB.process(ORB.java:1553)
   at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2680)
   at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2554)
   at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:62)
   at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
   at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1469)
Caused by: javax.naming.NameNotFoundException: Name comp/websphere not found in context "java:".
   at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
   at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
   at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
   at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
   at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
   ... 35 more
 
[21.02.07 08:45:54:795 CET] 00000012 RegisteredSyn E   WTRN0074E: Bei der Synchronisation von before_completion ist eine Ausnahme eingetreten: javax.persistence.PersistenceException: org.hibernate.HibernateException: javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the serverruntime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/websphere not found in context "java:".]
   at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:647)
   at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:509)
   at org.hibernate.transaction.MyWebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter$1.invoke(MyWebSphereExtendedJTATransactionLookup.java:139)
   at $Proxy15.beforeCompletion(Unknown Source)
   at com.ibm.ws.jtaextensions.SynchronizationCallbackWrapper.beforeCompletion(SynchronizationCallbackWrapper.java:65)
   at com.ibm.ws.Transaction.JTA.RegisteredSyncs.distributeBefore(RegisteredSyncs.java:240)
   at com.ibm.ws.Transaction.JTA.TransactionImpl.prePrepare(TransactionImpl.java:2373)   at com.ibm.ws.Transaction.JTA.TransactionImpl.stage1CommitProcessing(TransactionImpl.java:1606)
   at com.ibm.ws.Transaction.JTA.TransactionImpl.processCommit(TransactionImpl.java:1577)
   at com.ibm.ws.Transaction.JTA.TransactionImpl.commit(TransactionImpl.java:1512)
   at com.ibm.ws.Transaction.JTA.TranManagerImpl.commit(TranManagerImpl.java:237)
   at com.ibm.ws.Transaction.JTA.TranManagerSet.commit(TranManagerSet.java:162)
   at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:756)
   at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:181)
   at com.ibm.ejs.csi.TransactionControlImpl.postInvoke(TransactionControlImpl.java:581)
   at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3893)
   at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3715)
   at test.EJSRemoteStatelessService1_cf5b67a9.simpleSelectTest(EJSRemoteStatelessService1_cf5b67a9.java:382)
   at test._EJSRemoteStatelessService1_cf5b67a9_Tie.simpleSelectTest(_EJSRemoteStatelessService1_cf5b67a9_Tie.java:403)
   at test._EJSRemoteStatelessService1_cf5b67a9_Tie._invoke(_EJSRemoteStatelessService1_cf5b67a9_Tie.java:114)
   at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:613)
   at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:466)
   at com.ibm.rmi.iiop.ORB.process(ORB.java:503)
   at com.ibm.CORBA.iiop.ORB.process(ORB.java:1553)
   at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2680)
   at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2554)
   at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:62)
   at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
   at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1469)
Caused by: org.hibernate.HibernateException: javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the serverruntime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/websphere not found in context "java:".]
   at org.hibernate.transaction.MyWebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.<init>(MyWebSphereExtendedJTATransactionLookup.java:121)
   at org.hibernate.transaction.MyWebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.<init>(MyWebSphereExtendedJTATransactionLookup.java:115)
   at org.hibernate.transaction.MyWebSphereExtendedJTATransactionLookup$TransactionManagerAdapter.getTransaction(MyWebSphereExtendedJTATransactionLookup.java:85)
   at org.hibernate.transaction.CMTTransaction.getTransaction(CMTTransaction.java:91)
   at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:489)
   ... 27 more
Caused by: javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the serverruntime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/websphere not found in context "java:".]
   at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:416)
   at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
   at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
   at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
   at javax.naming.InitialContext.lookup(InitialContext.java:363)
   at org.hibernate.transaction.MyWebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.<init>(MyWebSphereExtendedJTATransactionLookup.java:118)
   ... 31 more
Caused by: javax.naming.NameNotFoundException: Name comp/websphere not found in context "java:".
   at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
   at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
   at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
   at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
   at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
   ... 35 more

emmanuel · **Posted:** Tue Feb 27, 2007 7:22 pm

Too many questions in one post so I'll just anwer the one I remember.
Do not override the factory_class whrn using HEM
Try either WebSphereExtendedJTATransactionLookup or WebSphereTransactionManagerLookup, one of them is known to work.
MyWebSphereExtendedJTATransactionLookup is not part of the Hibernate distrubution, so who knows what it does.

HEM has been deployed successfully on WAS 6.1. actually, Seam is tested on WAS 6.1 and run on top of HEM

amunrah · **Joined:** Wed Jan 31, 2007 5:02 am **Posts:** 6

Hi Emmanuel,

thanks for your reply.

It was my first posting and I had so many questions... next time I will create a posting for each problem.

Removing the factory_class in persistence.xml works fine for single method boundary test cases getting entity manager accurate once.

But if one calls a remote parent transactional method (REQUIRED) getting an entity manager by JpaUtil shown above and changes some data using it, after calling an non-transactional bean-local child method from this parent method one can't see the changes made by the parent in the child method getting a second entity manager in the child method:

Code:

/* 
* transaction-attribute set to REQUIRED 
*/ 
public void myRemoteTestMethod() { 
       
    A a = new A(); // with id as pk 
    … 
    JpaUtil.getEntityManager("TestUnit").persist(a); 
    AssertNotNull(findA(a)); 
} 

private A findA(A a) { 
    return JpaUtil.getEntityManager("TestUnit").find(A.class, a.getId()); 
}

I expected to get two instances of the EM mapping to the same PersistenceContext (Session) but this isn't so. I debugged the HEM creation and found usage of sessionfactory.openSession(). On the other side I found hints in the community to use sessionfactory.getCurrentSession() under CMT for work without EM.

A solution seems to be usage of entity manager via a ThreadLocal. But this is dangerous because threads are reused by a thread pool ??

Another solution is to insert an explicite flush() before calling child method. But this is not that what I really want to do.

--------------
The configured MyWebSphereExtendedJTATransactionLookup is subclassed from WebSphereExtendedJTATransactionLookup and differs in one detail implementing a method to avoid UnsupportedOperationException
---------------

Tom.

emmanuel · **Posted:** Wed Mar 07, 2007 7:12 pm

getCurrentSession is probably a safer choice. In JavaEE the container is responsible for the PC sharing, not the persistence provider

amunrah · **Joined:** Wed Jan 31, 2007 5:02 am **Posts:** 6

Hi Emmanuel,

thanks for your reply.

Instantiating HEM twice dos'nt work proper under WAS 6.1 / CMT (see my previous reply).

But I found a solution working fine for all J2EE test cases (transaction propagation/isolation/locking....) without any warnings or exceptions and bugfixing needs:

Fall back to a HibernateUtil using SessionFactory, AnnotatedConfiguration and hibernate.cfg.xml and instantiate a CurrentEntityManager with current session gotten from SessionFactory.
In this case one can configure org.hibernate.transaction.MyWebSphereExtendedJTATransactionLookup or org.hibernate.transaction.WebSphereTransactionManagerLookup in conjunction with property hibernate.transaction.factory_class set to org.hibernate.transaction.CMTTransactionFactory.

Tom