Transaction problems in Stateless EJB

I have problems as follows. my client is a servlet which call method B in stateless ejb, In side of method B, there is a loop from which antoher method C in this same ejb is called repeatedly. I want each call of method C being a separate transaction. I can not make this work. the final result will always be one transaction from for loop. I set the transaction attribute as Requires for method B, and Requires New for method C. Please offer some help.
Thanks.
void ejbMethodB(){
where(mycondition)
ejbMethodC()
I like to make each call of ejbMethodC be a standalone transaction instaed of the running results from the whole loop being a transaction

First of all, thank you so much for your time.
I also doubt the problem is Resin. But "Required" attribut works fine. The following is the coding:
EJB implementation:
//mehtodB
public RequestResult getDailyCreateUpdateInfo(Request request)
throws RemoteException, ProcessException
boolean testFlag = false;
List resultList = null;
ClaimsDAO dao = null;
Map mapRequestData = getRequestData(request);
int num = 0;
InterfacePushProcess push_process = (InterfacePushProcessRemote)(mySessionCtx.getEJBLocalObject());
try {
//Call DAO and get Student, ExchangeVisitor and their dependent information
dao = (ClaimsDAO) getEntityObject(ClaimsDAO.class.getName());
dataPushBO = new ClaimsDataImpl(mapRequestData);
//get the list of categories for DOS or US-VISIT
interdataList = dataPushBO.createCategoryList();
Iterator iterator = interdataList.iterator();
System.out.println("before invokeTransacprocess. ");
//testing
this.invokeTransacProcess();
//process all the categories for DOS or US-VISIT
while(iterator.hasNext())
interconfigData = (InterfaceDataConfig) iterator.next();
processOneCategory(mapRequestData, interconfigData, dao);
} catch (Exception e) {
mySessionCtx.setRollbackOnly();
log.logp(Level.SEVERE, classname, "getDailyCreateUpdateInfo", e.getMessage());
Object[] args = createExceptionArgs();
args[0] = request.getName();
throw new ProcessException(IMessage.ENTITY_POPULATION_FAILED, args, e);
return new RequestResult(request, resultList);
//mehtodC
public void processOneCategory(Map reqmap, InterfaceDataConfig interconfigData, ClaimsDAO dao)
throws ProcessException
List pageList = null;
String fileType = interconfigData.getGroupName(); //student, dep etc
String countKey = interconfigData.getCountKey();
String logKey = interconfigData.getIDKey();
UserTransaction trans = null;
int count = 0;
boolean process = false;
String groupname = interconfigData.getGroupName();
log.logp(Level.INFO, classname, "processOneCategory() ", "group name = " + groupname);
try
Context ct = new InitialContext();
trans = (UserTransaction) ct.lookup("java:comp/UserTransaction");
trans.begin();
String startTime = convert.getTimestamp();
log.logp( Level.INFO, classname, "processOneCategory() ", "processing start time: "+startTime);
pageList = processOnePage(interconfigData, dao);
if (pageList.isEmpty())
log.info("There are no records which need be processed.");
else
do
try
this.displayResult(pageList);
process = pageOutputProcessor(reqmap, interconfigData, pageList);
pageList.clear();
pageList = this.processOnePage(interconfigData, dao);
} catch (Exception ex) {
mySessionCtx.setRollbackOnly();
String msg = "Error while processing one page : " + ex.getMessage();
log.logp(Level.SEVERE, classname, "processOneCategory() ", msg);
throw new ProcessException(msg);
} while (!pageList.isEmpty());
//testing separate transaction
if(groupname.equalsIgnoreCase("STUDENT"))
trans.commit();
else
trans.rollback();
} catch (Exception t) {
mySessionCtx.setRollbackOnly();
String m = "Error when processing results from ClaimsDAO's : " + t.getMessage();
log.logp(Level.SEVERE, classname, "processOneCategory() ", m);
throw new ProcessException(m);
} finally {
I put both methods: getDailyCreateUpdateInfo and processOneCategory in remote interface so I can use your suggested method to reference the EJB instance.
Servlet Client call "getDailyCreateUpdateInfo" method (the transaction attribute is Required) in which call processOneCategory(,,) method (transaction attribute is RequiresNew).
I put some testing code to see if I can achieve the separate transaction in each call of mehtod processOneCategory(,,) , it does not work. If I use Bean Managed Transaction, it works right away. My app. server is Resin 2.1.4.
Again, Thank you.
Mark

Similar Messages

  • Transaction problem with stateless EJB and DAO

    Hi,
    I'm using a stateless session bean with container managed transaction and I have a method, which updates a row via CMP entity bean and then calls stored procedure, using a DAO object, which has to use the updated data. Both calls must be done in one transaction. The problem is that the stored procedure doesn't see the changes made from the update via CMP EJB, but after the method exits the changes are in the database. I'm using WebSphere 4.0.3 and DB2 7.2. Method code example in the stateless bean:
    public doIt(ValueObject vo) throws ... {
    OrderPosRemote opr = getOrderPosRemote();
    opr.update(vo);
    getDAO().recalc(vo);
    } catch (DAOException daoex) {
    getSessionContext().setRollbackOnly();
    And in the DAO:
    public boolean recalc(...) throws DAOException {
    Connection conn = getConnFromDataSource();
    CallableStatement cstmt = conn.prepareCall("call ...(?,?)");
    cstmt.execute();
    ... // close cstmt and release connection to the pool
    Any help will be highly appreciated !

    Hi meadandale,
    this was my first guess too and I set this attribute in the session bean method, then into the update method of the CMP bean and "manually" to the connection object in the DAO like this:
    conn.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
    The isolation level is set correctly (IMHO), because when I comment the line above in the DAO, an exception is thrown stating that the isolation level can't be changed within a transaction.
    Unfortenully this didn't help too. Should I set some special attribute to the database or connection pool additionally ?
    I don't understand what is the problem actually - it is definitely one transaction and why this doesn't work is not very clear to me ...

  • HOWTO: Using a BC4J Application Module in an Stateless EJB Session Bean

    HOWTO: Using a BC4J Application Module in an Stateless EJB Session Bean
    by Steve Muench
    Overview
    BC4J provides automatic facilities for deploying any application module as a stateful EJB session bean. If you want to leverage the features of your BC4J application module from a stateless EJB session bean, it's not automatic but it is straightforward to implement. This howto article explains the details.
    For our example, we will create a stateless EJB session bean that uses a container-managed transaction. To keep things simple, let's assume the session bean has a single public method on its remote interface named createDepartment() with the following signature:
    public void createDepartment(int id, String name, String loc) throws AppException
    AppException is an example of an application-specific exception that our method will throw if any problems arise during its execution.The goal of this article is to illustrate how to use the BC4J application module named com.example.hr.HRApp as part of the implementation of this createDepartment method on our stateless enterprise bean. Let's assume that the HRApp application module has a view object member named Departments, based on the com.example.hr.DeptView view object, based on the familiar DEPT table and related to the com.example.hr.Dept entity object so our view can be updateable.
    Creating the Stateless Session Bean
    We can start by using the JDeveloper Enterprise Bean wizard to create a new stateless session bean called StatelessSampleEJB implemented by:[list][*]com.example.StatelessSampleEJBBean (Bean class)[*]com.example.StatelessSampleEJBHome (Home interface)[*]com.example.StatelessSampleEJB (Remote interface)[list]
    We then use the EJB Class Editor to add the createDepartment method to the remote interface of StatelessSampleEJB with the signature above. We edit the remote interface to make sure that it also reflects that the createDepartment method thows the AppException like this:
    package com.example;
    import javax.ejb.EJBObject;
    import java.rmi.RemoteException;
    public interface StatelessSampleEJB extends EJBObject {
      void createDepartment(int id, String name, String loc)
      throws RemoteException,AppException;
    }Before we start adding BC4J into the picture for our implementation, our StatelessSampleEJBBean class looks like this:
    package com.example;
    import javax.ejb.SessionBean;
    import javax.ejb.SessionContext;
    public class StatelessSampleEJBBean implements SessionBean {
      public void ejbCreate(){}
      public void ejbActivate(){}
      public void ejbPassivate(){}
      public void ejbRemove(){}
      public void setSessionContext(SessionContext ctx){
      public void createDepartment(int id, String name, String loc) 
      throws AppException {
        // TODO: Implement method here
    }We can double-click on the ejb-jar.xml file in our project to see the XML deployment descriptor for the bean we just created:
    <ejb-jar>
       <enterprise-beans>
          <session>
             <description>Session Bean ( Stateless )</description>
             <display-name>StatelessSampleEJB</display-name>
             <ejb-name>StatelessSampleEJB</ejb-name>
             <home>com.example.StatelessSampleEJBHome</home>
             <remote>com.example.StatelessSampleEJB</remote>
             <ejb-class>com.example.StatelessSampleEJBBean</ejb-class>
             <session-type>Stateless</session-type>
             <transaction-type>Container</transaction-type>
          </session>
       </enterprise-beans>
    </ejb-jar>We need to add the extra <assembly-descriptor> section in this file to indicate that the createDepartment method will require a transaction. After this edit, the ejb-jar.xml file looks like this:
    <ejb-jar>
       <enterprise-beans>
          <session>
             <description>Session Bean ( Stateless )</description>
             <display-name>StatelessSampleEJB</display-name>
             <ejb-name>StatelessSampleEJB</ejb-name>
             <home>com.example.StatelessSampleEJBHome</home>
             <remote>com.example.StatelessSampleEJB</remote>
             <ejb-class>com.example.StatelessSampleEJBBean</ejb-class>
             <session-type>Stateless</session-type>
             <transaction-type>Container</transaction-type>
          </session>
       </enterprise-beans>
       <assembly-descriptor>
          <container-transaction>
             <method>
                <ejb-name>StatelessSampleEJB</ejb-name>
                <method-name>createDepartment</method-name>
                <method-params>
                   <method-param>int</method-param>
                   <method-param>java.lang.String</method-param>
                   <method-param>java.lang.String</method-param>
                </method-params>
             </method>
             <trans-attribute>Required</trans-attribute>
          </container-transaction>
       </assembly-descriptor>
    </ejb-jar>
    Aggregating a BC4J Application Module
    With the EJB aspects of our bean setup, we can proceed to implementing the BC4J application module aggregation.
    The first thing we do is add private variables to hold the EJB SessionContext and the instance of the aggregated BC4J ApplicationModule, like this:
    // Place to hold onto the aggregated appmodule instance
    transient private ApplicationModule _am  = null;
    // Remember the SessionContext that the EJB container provides us
    private           SessionContext    _ctx = null;and we modify the default, empty implementation of the setSessionContext() method to remember the session context like this:
    public void setSessionContext(SessionContext ctx){ _ctx = ctx; }We add additional constants that hold the names of the J2EE datasource that we want BC4J to use, as well as the fully-qualified name of the BC4J application module that we'll be aggregating:
    // JNDI resource name for the J2EE datasource to use
    private static final String DATASOURCE = "jdbc/OracleCoreDS";
    // Fully-qualified BC4J application module name to aggregate
    private static final String APPMODNAME = "com.example.hr.HRApp";We expand the now-empty ejbCreate() and ejbRemove() methods to create and destory the aggregated instance of the BC4J application module that we'll use for the lifetime of the stateless session bean. When we're done, ejbCreate() it looks like this:
    public void ejbCreate() throws CreateException {
      try {
        // Setup a hashtable of environment parameters for JNDI initial context
        Hashtable env = new Hashtable();
        env.put(JboContext.INITIAL_CONTEXT_FACTORY,JboContext.JBO_CONTEXT_FACTORY);
        // NOTE: we want to use the BC4J app module in local mode as a simple Java class!
        env.put(JboContext.DEPLOY_PLATFORM, JboContext.PLATFORM_LOCAL);
        env.put(PropertyConstants.INTERNAL_CONNECTION_PARAMS,DATASOURCE);
        // Create an initial context, using this hashtable of environment params
        InitialContext ic = new InitialContext(env);
        // Lookup a home interface for the application module
        ApplicationModuleHome home = (ApplicationModuleHome)ic.lookup(APPMODNAME);
        // Using the home, create the instance of the appmodule we'll use
        _am = home.create();
        // Register the BC4J factory to handle EJB container-managed transactions
        registerContainerManagedTransactionHandlerFactory();
      catch(Exception ex) {
         ex.printStackTrace();
        throw new CreateException(ex.getMessage());
    }and ejbRemove() looks like this:
    public void ejbRemove() {
      try {
        // Cleanup any appmodule resources before getting shutdown
        _am.remove();
      catch(JboException ex) { /* Ignore */ }
    }The helper method named reigsterContainerManagedTransactionHandlerFactory() looks like this:
    private void registerContainerManagedTransactionHandlerFactory() {
      SessionImpl session = (SessionImpl)_am.getSession();
      session.setTransactionHandlerFactory(
        new TransactionHandlerFactory() {
          public TransactionHandler  createTransactionHandler() {
            return new ContainerManagedTxnHandlerImpl();
          public JTATransactionHandler createJTATransactionHandler() {
            return new ContainerManagedTxnHandlerImpl();
    }The last detail is to use the BC4J appmodule to implement the createDepartment() method. It ends up looking like this:
    public void createDepartment(int id, String name, String loc)
    throws AppException {
      try {
        // Connect the AM to the datasource we want to use for the duration
        // of this single method call.
        _am.getTransaction().connectToDataSource(null,DATASOURCE,false);
        // Use the "Departments" view object member of this AM
        ViewObject departments = _am.findViewObject("Departments");
        // Create a new row in this view object.
        Row newDept = departments.createRow();
        // Populate the attributes from the parameter arguments.
        newDept.setAttribute("Deptno", new Number(id));
        newDept.setAttribute("Dname", name);
        newDept.setAttribute("Loc", loc);
        // Add the new row to the view object's default rowset
        departments.insertRow(newDept);
        // Post all changes in the AM, but we don't commit them. The EJB
        // container managed transaction handles the commit.
        _am.getTransaction().postChanges();
      catch(JboException ex) {
        // To be good EJB Container-Managed Transaction "citizens" we have
        // to mark the transaction as needing a rollback if there are problems
        _ctx.setRollbackOnly();
        throw new AppException("Error creating dept "+ id +"\n"+ex.getMessage());
      finally {
        try {
          // Disconnect the AM from the datasource we're using
          _am.getTransaction().disconnect();
        catch(Exception ex) { /* Ignore */ }
    Building a Test Client
    With the EJB-Tier work done, we can build a sample client program to test this new stateless EJB Session Bean by selecting the bean in the Oracle9i JDeveloper IDE and choosing "Create Sample Java Client" from the right-mouse menu.
    When the "Sample EJB Client Details" dialog appears, we take the defaults of connecting to embedded OC4J container. Clicking the (OK) button generates the following test class:
    import java.util.Hashtable;
    import javax.naming.Context;
    import javax.naming.InitialContext;
    import com.example.StatelessSampleEJB;
    import com.example.StatelessSampleEJBHome;
    public class SampleStatelessSampleEJBClient {
      public static void main(String [] args) {
        SampleStatelessSampleEJBClient sampleStatelessSampleEJBClient =
           new SampleStatelessSampleEJBClient();
        try {
          Hashtable env = new Hashtable();
          env.put(Context.INITIAL_CONTEXT_FACTORY,
                  "com.evermind.server.rmi.RMIInitialContextFactory");
          env.put(Context.SECURITY_PRINCIPAL, "admin");
          env.put(Context.SECURITY_CREDENTIALS, "welcome");
          env.put(Context.PROVIDER_URL,
                  "ormi://localhost:23891/current-workspace-app");
          Context ctx = new InitialContext(env);
          StatelessSampleEJBHome statelessSampleEJBHome =
               (StatelessSampleEJBHome)ctx.lookup("StatelessSampleEJB");
          StatelessSampleEJB statelessSampleEJB;
          // Use one of the create() methods below to create a new instance
          // statelessSampleEJB = statelessSampleEJBHome.create();
          // Call any of the Remote methods below to access the EJB
          // statelessSampleEJB.createDepartment( int id, java.lang.String name, java.lang.String loc );
        catch(Throwable ex) {
          ex.printStackTrace();
    }We uncomment the call to the create() method and add a few calls to the createDepartment() method so that the body of the test program now looks like this:
    // Use one of the create() methods below to create a new instance
    statelessSampleEJB = statelessSampleEJBHome.create();
    // Call any of the Remote methods below to access the EJB
    statelessSampleEJB.createDepartment( 13, "Test1","Loc1");
    System.out.println("Created department 13");
    statelessSampleEJB.createDepartment( 14, "Test2","Loc2");
    System.out.println("Created department 14");
    try {
      // Try setting a department id that is too large!
      statelessSampleEJB.createDepartment( 23456, "Test3","Loc3");
    catch (AppException ax) {
      System.err.println("AppException: "+ax.getMessage());
    }Before we can successfully run our SampleStatelessSampleEJBClient we need to first run the EJB bean that the client will try to connect to. Since Oracle9i JDeveloper supports local running and debugging of the EJB-Tier without doing through a full J2EE deployment step, to accomplish this prerequisite step we just need to right-mouse on the StatelessSampleEJB node in the System Navigator and select "Run". This starts up the embedded OC4J instance and runs the EJB right out of the current out path.Finally, we can run the SampleStatelessSampleEJBClient, and see the output of the test program in the JDeveloper log window:
    Created department 13
    Created department 14
    AppException: Error creating dept 23456
    JBO-27010: Attribute set with value 23456 for Deptno in Dept has invalid precision/scale
    Troubleshooting
    One error that might arise while running the example is that the database connection information in your data-sources.xml for the jdbc/OracleCoreDS datasource does not correspond to the database you are trying to test against. If this happens, then double-check the file .\jdev\system\oc4j-config\data-sources.xml under the JDeveloper installation home directory to make sure that the url value provided is what you expect. For example, to work against a local Oracle database running on your current machine, listening on port 1521, with SID of ORCL, you would edit this file to have an entry like this for jdbc/OracleCoreDS :
    <data-source
        class="com.evermind.sql.DriverManagerDataSource"
        name="OracleDS"
        location="jdbc/OracleCoreDS"
        xa-location="jdbc/xa/OracleXADS"
        ejb-location="jdbc/OracleDS"
        connection-driver="oracle.jdbc.driver.OracleDriver"
        username="scott"
        password="tiger"
        url="jdbc:oracle:thin:@localhost:1521:ORCL"
        inactivity-timeout="30"
    />This is the data-sources.xml file that gets used by the embedded OC4J instance running in JDeveloper.
    Conclusion
    Hopefully this article has illustrated that it is straightforward to utilize the full power of BC4J in local mode as part of your EJB Stateless Session Beans using container-managed transaction. This example illustrated a single createDepartment method in the enterprise bean, but by replicating the application module interaction code that we've illustrated in createDepartment, any number of methods in your stateless session bean can use the aggregated application module instance created in the ejbCreate() method.
    Code Listing
    The full code listing for the SampleStatelessEJB bean implementation class looks like this:
    * StatelessSampleEJB
    * Illustrates how to use an aggregated BC4J application module
    * in local mode as part of the implementation of a stateless
    * EJB session bean using container-managed transaction.
    * HISTORY
    * smuench/dmutreja 14-FEB-2002 Created
    package com.example;
    import oracle.jbo.*;
    import oracle.jbo.server.*;
    import javax.ejb.*;
    import oracle.jbo.domain.Number;
    import oracle.jbo.common.PropertyConstants;
    import java.util.Hashtable;
    import javax.naming.InitialContext;
    import oracle.jbo.server.ejb.ContainerManagedTxnHandlerImpl;
    public class StatelessSampleEJBBean implements SessionBean {
      // JNDI resource name for the J2EE datasource to use
      private static final String DATASOURCE = "jdbc/OracleCoreDS";
      // Fully-qualified BC4J application module name to aggregate
      private static final String APPMODNAME = "com.example.hr.HRApp";
      // Place to hold onto the aggregated appmodule instance
      transient private ApplicationModule _am  = null;
      // Remember the SessionContext that the EJB container provides us
      private           SessionContext    _ctx = null;
      public void ejbCreate() throws CreateException {
        try {
          // Setup a hashtable of environment parameters for JNDI initial context
          Hashtable env = new Hashtable();
          env.put(JboContext.INITIAL_CONTEXT_FACTORY,JboContext.JBO_CONTEXT_FACTORY);
          env.put(JboContext.DEPLOY_PLATFORM, JboContext.PLATFORM_LOCAL);
          env.put(PropertyConstants.INTERNAL_CONNECTION_PARAMS,DATASOURCE);
          // Create an initial context, using this hashtable of environment params
          InitialContext ic = new InitialContext(env);
          // Lookup a home interface for the application module
          ApplicationModuleHome home = (ApplicationModuleHome)ic.lookup(APPMODNAME);
          // Using the home, create the instance of the appmodule we'll use
          _am = home.create();
          // Register the BC4J factory to handle EJB container-managed transactions
          registerContainerManagedTransactionHandlerFactory();
        catch(Exception ex) {
           ex.printStackTrace();
          throw new CreateException(ex.getMessage());
      public void ejbActivate(){}
      public void ejbPassivate(){}
      public void ejbRemove(){}
      public void setSessionContext(SessionContext ctx){ _ctx = ctx; }
      public void createDepartment(int id, String name, String loc)
      throws AppException {
        try {
          // Connect the AM to the datasource we want to use for the duration
          // of this single method call.
          _am.getTransaction().connectToDataSource(null,DATASOURCE,false);
          // Use the "Departments" view object member of this AM
          ViewObject departments = _am.findViewObject("Departments");
          // Create a new row in this view object.
          Row newDept = departments.createRow();
          // Populate the attributes from the parameter arguments.
          newDept.setAttribute("Deptno", new Number(id));
          newDept.setAttribute("Dname", name);
          newDept.setAttribute("Loc", loc);
          // Add the new row to the view object's default rowset
          departments.insertRow(newDept);
          // Post all changes in the AM, but we don't commit them. The EJB
          // container managed transaction handles the commit.
          _am.getTransaction().postChanges();
        catch(JboException ex) {
          // To be good EJB Container-Managed Transaction "citizens" we have
          // to mark the transaction as needing a rollback if there are problems
          _ctx.setRollbackOnly();
          throw new AppException("Error creating dept "+ id +\n"+ex.getMessage());
        finally {
          try {
            // Disconnect the AM from the datasource we're using
            _am.getTransaction().disconnect();
          catch(Exception ex) { /* Ignore */ }
      private void registerContainerManagedTransactionHandlerFactory() {
        SessionImpl session = (SessionImpl)_am.getSession();
        session.setTransactionHandlerFactory(
          new TransactionHandlerFactory() {
            public TransactionHandler createTransactionHandler() {
              return new ContainerManagedTxnHandlerImpl();
            public JTATransactionHandler createJTATransactionHandler() {
              return new ContainerManagedTxnHandlerImpl();

    Hi Steve, It4s me again;
    About the question I made, I tried with a single assembly-descriptor tag and a single container-transaction tag in the deployment descriptor of the session bean and these were the results.
    java.lang.NullPointerException
         void com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(java.lang.Throwable)
         java.lang.Object com.evermind.server.rmi.RMIConnection.invokeMethod(com.evermind.server.rmi.RMIContext, long, long, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         void __Proxy1.modificaEnvoltura(java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.String)
         void SamplemdeController.envolturaControlEJBClient.main(java.lang.String[])
    Then I tried with multiple assembly-descriptor tags each with a single container-transaction tag and the results were:
    java.lang.NullPointerException
         void com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(java.lang.Throwable)
         java.lang.Object com.evermind.server.rmi.RMIConnection.invokeMethod(com.evermind.server.rmi.RMIContext, long, long, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         void __Proxy1.modificaEnvoltura(java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.String)
         void SamplemdeController.envolturaControlEJBClient.main(java.lang.String[])
    Finally I tried with a single assembly-descriptor and multiple container tags and the results were:
    java.lang.NullPointerException
         void com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(java.lang.Throwable)
         java.lang.Object com.evermind.server.rmi.RMIConnection.invokeMethod(com.evermind.server.rmi.RMIContext, long, long, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         void __Proxy1.modificaEnvoltura(java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.String)
         void SamplemdeController.envolturaControlEJBClient.main(java.lang.String[])
    How can I make my Stateless Session bean work out?

  • Not be able to obtain a transacted session within stateless session bean

    I need some assistance on creating a transacted session. For some reason while within a stateless session bean, I am unable to create a transacted session even though I'm specifying to create the transacted queue session. Can anyone provide any assistance to me on this? It would be much appreciated.
    Here is the code snippets involved with the problem:
    Code snipet from ejb-jar.xml:
    <session>
    <display-name>Initial Request</display-name>
    <ejb-name>InitialRequestBean</ejb-name>
    <ejb-class>com.raytheon.rds.jms.InitialRequestBean</ejb-class>
    <session-type>Stateless</session-type>
    <transaction-type>Container</transaction-type>
    </session>
    Code from stateless session bean:
    static Logger logger;
    private QueueConnectionFactory connectionFactory;
    private SessionContext sc;
    private Queue requestQueue;
    public String processRequest(String msgBody)
    logger.log(Level.INFO, "In processRequest(String).", msgBody);
    QueueConnection con = null;
    QueueSession session = null;
    QueueSender sender = null;
    TextMessage message = null;
    String messageID = null;
    QueueReceiver receiver = null;
    TemporaryQueue replyQueue = null;
    boolean transacted = false;
    try
    //Create the infrastructure (ie. The connection & the session)
    logger.log(Level.FINE, "Creating connection");
    con = connectionFactory.createQueueConnection();
    logger.log(Level.FINE, "Creating session");
    session = con.createQueueSession(true, Session.AUTO_ACKNOWLEDGE);
    //Note: This line above was changed in all possible permutation and still didn't work such as using Session.SESSION_TRANSACTED
    transacted = session.getTransacted();
    logger.log(Level.FINE, "Is session transacted? : " + transacted);
    //Note: This line above is constantly saying false
    //Now first, setup the temporary reply queue and its listener
    replyQueue = session.createTemporaryQueue();
    logger.log(Level.FINE, "Creating receiver/consumer");
    receiver = session.createReceiver(replyQueue);
    con.start();
    //Now create the requestor that will make the request message and put it on the request queue
    logger.log(Level.FINE, "Creating Requestor/Producer");
    sender = session.createSender(requestQueue);
    //Now create the message and make sure that you put the "JMSReplyTo" property to the temporary response queue we just created
    message = session.createTextMessage();
    message.setJMSReplyTo(replyQueue);
    logger.log(Level.FINE, "Created message: " + message.getJMSMessageID());
    //Now add the actual info you want to send
    message.setText(msgBody);
    //Now send the message
    logger.log(Level.INFO, "Sending message: " + message.getText());
    sender.send(message);
    //Now wait until we get a response
    logger.log(Level.FINE, "Waiting for the response message");
    Message responseMsg = receiver.receive(20000); //Toggle the "0" to specify timeout in millisectionds
    //Process the message
    logger.log(Level.FINE, "Processing the response message");
    if(null != responseMsg)
    logger.log(Level.FINE, "responseMsg is : " + responseMsg.toString());
    messageID = processMessage(responseMsg);
    logger.log(Level.FINE, "Response is : " + messageID);
    //close the connection
    logger.log(Level.FINE, "Stopping the connection");
    con.stop();
    catch (Throwable t)
    // JMSException could be thrown
    logger.log(Level.SEVERE, "Exception Thrown in sendRequest: ", t);
    sc.setRollbackOnly();
    finally
    //Close the sender
    if (sender != null)
    try
    logger.log(Level.FINE, "Closing the sender");
    sender.close();
    catch (JMSException e)
    logger.log(Level.WARNING, "JMSException Thrown when trying to close the sender to the request queue: ", e);
    else
    logger.log(Level.FINE, "Sender is already closed.");
    //Close the receiver
    if (receiver != null)
    try
    logger.log(Level.FINE, "Closing the receiver");
    receiver.close();
    catch (JMSException e)
    logger.log(Level.WARNING, "JMSException Thrown when trying to close the receiver to the request queue: ", e);
    else
    logger.log(Level.FINE, "Receiver is already closed.");
    //Close the session
    if (session != null)
    try
    logger.log(Level.FINE, "Closing the session");
    session.close();
    catch (JMSException e)
    logger.log(Level.WARNING, "JMSException Thrown when trying to close the session to the request queue: ", e);
    else
    logger.log(Level.FINE, "Session is already closed.");
    //Close the connection
    if (con != null)
    try
    logger.log(Level.FINE, "Closing the connection");
    con.close();
    catch (JMSException e)
    logger.log(Level.WARNING, "JMSException Thrown when trying to close the connection to the reply queue: ", e);
    else
    logger.log(Level.FINE, "Connection is already closed.");
    return messageID;
    }

    I found the answer through lots of painful searching.
    http://blogs.sun.com/fkieviet/entry/request_reply_from_an_ejb
    This weblog from Frank Kieviet from a sun blog explains what's happening behind the scenes.
    Then I proceeded to create a Bean-Managed Transaction out of my EJB, which is using EJB 3.0. This requires the tag:
    @TransactionManagement(value= TransactionManagementType.BEAN)
    Note: I got this information from http://download.oracle.com/docs/cd/B31017_01/web.1013/b28221/servtran001.htm#BAJIBAFF
    Then I just added the code specified in Frank's blog and everything is working now. The main portion of the code looks like this now:
    //begin the user transaction
    ctx.getUserTransaction().begin();
    //Create the infrastructure (ie. The connection & the session)
    logger.log(Level.FINE, "Creating connection");
    con = connectionFactory.createQueueConnection();
    //Create the session
    logger.log(Level.FINE, "Creating session");
    session = con.createQueueSession(false, Session.SESSION_TRANSACTED);
    transacted = session.getTransacted();
    logger.log(Level.FINE, "Is session transacted? : " + transacted);
    //Now create the sender that will make the request message and put it on the request queue
    logger.log(Level.FINE, "Creating Sender");
    sender = session.createSender(requestQueue);
    //Now create the message
    message = session.createTextMessage();
    //Now add the actual info you want to send
    message.setText(msgBody);
    logger.log(Level.FINE, "Created message: " + message.getJMSMessageID());
    //Now first, setup the temporary reply queue and its listener
    replyQueue = session.createTemporaryQueue();
    if(null != replyQueue)
    logger.log(Level.FINE, "Created temporary queue: " + replyQueue.getQueueName());
    else
    logger.log(Level.FINE, "Temporary Queue could not be created.");
    //make sure that you put the "JMSReplyTo" property to the temporary response queue we just created
    message.setJMSReplyTo(replyQueue);
    //Now send the message
    logger.log(Level.INFO, "Sending message: " + message.getText());
    sender.send(message);
    //Now start the connection
    logger.log(Level.FINE, "Starting the connection");
    con.start();
    //commit the changes
    ctx.getUserTransaction().commit();
    ctx.getUserTransaction().begin();
    //Create the receiver
    logger.log(Level.FINE, "Creating Receiver");
    receiver = session.createReceiver(replyQueue);
    //Now wait until we get a response
    logger.log(Level.FINE, "Waiting for the response message");
    Message responseMsg = receiver.receive(20000); //Toggle the "0" to specify timeout in millisectionds
    //Process the message
    logger.log(Level.FINE, "Processing the response message");
    if(null != responseMsg)
    logger.log(Level.FINE, "responseMsg is : " + responseMsg.toString());
    else
    logger.log(Level.FINE, "No response came back.");
    messageID = processMessage(responseMsg);
    logger.log(Level.FINE, "Response is : " + messageID);
    logger.log(Level.FINE, "Transaction is complete");
    //commit the changes
    ctx.getUserTransaction().commit();

  • Transaction Problem - Timeout

    Folks
    I am experiencing a Transaction timeout error on a supposed non-transacted method.
    Here's the scoop. The Stateless Session bean MemberManager has the Transaction
    Attribute set either as "SUPPORTS" or "REQUIRED". Gets and Finds are set to "SUPPORTS"
    The Entity beans MemberBean and PolicyHolderBean have all method transaction
    attributes set to SUPPORTS. As you can tell transaction mgt is handled at the
    SBlevel.
    <container-transaction>
    <method>
    <ejb-name>MemberManager</ejb-name>
    <method-name>getMemberModel</method-name>
    </method>
    <trans-attribute>Supports</trans-attribute>
    </container-transaction>
    <container-transaction>
    <method>
    <ejb-name>MemberBean</ejb-name>
    <method-name>*</method-name>
    </method>
    <trans-attribute>Supports</trans-attribute>
    </container-transaction>
    <container-transaction>
    <method>
    <ejb-name>PolicyHolderBean</ejb-name>
    <method-name>*</method-name>
    </method>
    <trans-attribute>Supports</trans-attribute>
    </container-transaction>
    The call to MemberManager.getMemberModel is thus non-transacted. Yet I recieve
    (from time to time) a Transaction timeout on the PolicyHolderBean.findByPrimaryKey.
    (FYI there is a 1:1 CMR relationship between Member and PolicyHolder). The stack
    trace follows. Any help is appreciated. Why is this being transacted?
    ####<Sep 23, 2002 2:12:43 PM EDT> <Error> <com.hmcng.service.job.AbstractJob>
    <HMCAPPSVR3> <NextGen3> <Thread-111> <> <21104:3b4203690f8f04a5> <000000> <abstractjob.generate.exception.exception:
    letterservice.updatejobstatuserror.remoteexception: Message was not sent because
    transaction is not active. Name=[EJB com.hmcng.member.entity.MemberBean.findByPrimaryKey(java.lang.Integer)],Xid=21104:3b4203690f8f04a5(3304037),Status=Rolled
    back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed
    out after 33 seconds
    Name=[EJB com.hmcng.member.entity.MemberBean.findByPrimaryKey(java.lang.Integer)],Xid=21104:3b4203690f8f04a5(3304037),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
    since begin=33,seconds left=30,activeThread=Thread[Thread-111,2,main],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=none),SCInfo[hmc_letters+NextGen3]=(state=active),properties=({ISOLATION
    LEVEL=2, weblogic.transaction.name=[EJB com.hmcng.member.entity.MemberBean.findByPrimaryKey(java.lang.Integer)],
    weblogic.jdbc=t3://172.25.64.69:7901, LOCAL_ENTITY_TX=true}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=NextGen3+172.25.64.69:7901+hmc_letters+,
    Resources={})],CoordinatorURL=NextGen3+172.25.64.69:7901+hmc_letters+)],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
    since begin=66,seconds left=10,activeThread=Thread[Thread-111,2,main],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=rolledback,assigned=NextGen3),SCInfo[hmc_letters+NextGen3]=(state=rolledback),properties=({ISOLATION
    LEVEL=2, weblogic.transaction.name=[EJB com.hmcng.member.entity.MemberBean.findByPrimaryKey(java.lang.Integer)],
    weblogic.jdbc=t3://172.25.64.69:7901, LOCAL_ENTITY_TX=true}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=NextGen3+172.25.64.69:7901+hmc_letters+,
    Resources={})],CoordinatorURL=NextGen3+172.25.64.69:7901+hmc_letters+)>
    ####<Sep 23, 2002 2:12:43 PM EDT> <Error> <com.hmcng.service.job.AbstractJob>
    <HMCAPPSVR3> <NextGen3> <Thread-111> <> <21104:3b4203690f8f04a5> <000000> <abstractjob.generate.exception:
    memberservice.getmembermodel.remoteexception: member.unable.to.find.member: Problem
    in findByPrimaryKey while preparing or executing statement: 'weblogic.jdbc.rmi.SerialPreparedStatement@14b404':
    java.sql.SQLException: The transaction is no longer active (status = Rolling Back.
    [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out
    after 33 seconds
    Name=[EJB com.hmcng.member.entity.MemberBean.findByPrimaryKey(java.lang.Integer)],Xid=21104:3b4203690f8f04a5(3304037),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
    since begin=33,seconds left=30,activeThread=Thread[Thread-111,2,main],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=none),SCInfo[hmc_letters+NextGen3]=(state=active),properties=({ISOLATION
    LEVEL=2, weblogic.transaction.name=[EJB com.hmcng.member.entity.MemberBean.findByPrimaryKey(java.lang.Integer)],
    weblogic.jdbc=t3://172.25.64.69:7901, LOCAL_ENTITY_TX=true}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=NextGen3+172.25.64.69:7901+hmc_letters+,
    Resources={})],CoordinatorURL=NextGen3+172.25.64.69:7901+hmc_letters+)]). No further
    JDBC access is allowed within this transaction.
    java.sql.SQLException: The transaction is no longer active (status = Rolling Back.
    [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out
    after 33 seconds
    Name=[EJB com.hmcng.member.entity.MemberBean.findByPrimaryKey(java.lang.Integer)],Xid=21104:3b4203690f8f04a5(3304037),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
    since begin=33,seconds left=30,activeThread=Thread[Thread-111,2,main],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=none),SCInfo[hmc_letters+NextGen3]=(state=active),properties=({ISOLATION
    LEVEL=2, weblogic.transaction.name=[EJB com.hmcng.member.entity.MemberBean.findByPrimaryKey(java.lang.Integer)],
    weblogic.jdbc=t3://172.25.64.69:7901, LOCAL_ENTITY_TX=true}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=NextGen3+172.25.64.69:7901+hmc_letters+,
    Resources={})],CoordinatorURL=NextGen3+172.25.64.69:7901+hmc_letters+)]). No further
    JDBC access is allowed within this transaction.
    at weblogic.jdbc.jts.Connection.checkIfRolledBack(Connection.java:508)

              "Jeremy Meyer" <[email protected]> wrote:
              >I am running WL 6.0 on Win NT 4.0 SP 6
              >
              >I am having a problem with a transaction timing out while doing some stuff
              >with EJBs. They do some calculations that can take a few minutes and thus
              >the transactions must last that long but they are timing out after 30
              >seconds. I went to the console and changed the timeout time to a higher
              >setting. This seemed to work but then when I did the same thing a little
              >while later it timed out after 30 seconds again. I look at the console and
              >it says the timeout time is 180 seconds. Any thoughts on what I am doing
              >wrong/why it is acting this way? Thanks.
              Ugh. This is a known problem. As it turns out, EJB's deployment descriptor defaults
              to 30 seconds if a timeout value is not specified. It then overrides the JTA subsystem's
              default timeout settings.
              The workaround is to always specify a valid transaction timeout in the EJB's DD,
              and not to let it default.
              -Sriram
              

  • Stateless EJB using Threads

    Helo Everyone !
    Recently I developed a Stateless EJB where I used a Thread to receive asynchronously client calls. After that I read some Bea articles describing the MDB (Message Drive Beans) and I discovered another way to resolve asynchronously calls. By the way I'd like to know if I can have some problems in the future using threads instead MDB. Do you know some articles where bea doesn't approve the threads usage.
    Thank you
    Regards

    If you're using WLS 9.x, then I'd suggest you have a look at the WorkManager API. It allows you to start asynchronous work (in a BEA-approved way) and have it just invoke a java.lang.Runnable.
    I would use a MDB if you want transactions or you want the scheduled work to be persistent or highly-available.
    While many customers do it, we attempt to discourage users creating threads in the server.
    -- Rob
    WLS Blog http://dev2dev.bea.com/blog/rwoollen/

  • Stateless EJB 3.0 to webservice

    Hello,
    I'm using EJB 3.0 deployed on weblogic server 10. I can deploy Stateless EJB without any problem.
    If I add a @WebService tag above my stateless bean, my deployment fails with the following error:
    Exception activating module: EJBModule(EfanetTA_EJB.jar) Unable to deploy EJB: ProfilesFacade from EfanetTA_EJB.jar: Unable to deploy EJB: EfanetTA_EJB.jar from EfanetTA_EJB.jar: [HTTP:101216]Servlet: "WSEE_SERVLET" failed to preload on startup in Web application: "/BusinessManager". class: lu.efa.ejb.jaxws.FindProfilesById could not be found at com.sun.xml.ws.model.RuntimeModeler.getClass(RuntimeModeler.java:272) at com.sun.xml.ws.model.RuntimeModeler.processDocWrappedMethod(RuntimeModeler.java:566) at com.sun.xml.ws.model.RuntimeModeler.processMethod(RuntimeModeler.java:513) at com.sun.xml.ws.model.RuntimeModeler.processClass(RuntimeModeler.java:358) at com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:245) at com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:229) at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:161) at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:291) at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:315) at weblogic.wsee.jaxws.JAXWSServlet.registerEndpoint(JAXWSServlet.java:125) at weblogic.wsee.jaxws.JAXWSServlet.init(JAXWSServlet.java:64) at javax.servlet.GenericServlet.init(GenericServlet.java:241) at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:282) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(Unknown Source) at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:63) at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:58) at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:48) at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:504) at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:1830) at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:1807) at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1727) at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2890) at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:948) at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:353) at weblogic.wsee.deploy.WseeWebappModule.activate(WseeWebappModule.java:139) at weblogic.wsee.deploy.WSEEEjbModule.activate(WSEEEjbModule.java:371) at weblogic.wsee.deploy.WsEJBDeployListener.activate(WsEJBDeployListener.java:52) at weblogic.ejb.container.deployer.EJBDeployer.activate(EJBDeployer.java:1414) at weblogic.ejb.container.deployer.EJBModule.activate(EJBModule.java:423) at weblogic.application.internal.flow.ModuleListenerInvoker.activate(ModuleListenerInvoker.java:107) at weblogic.application.internal.flow.DeploymentCallbackFlow$2.next(DeploymentCallbackFlow.java:381) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.flow.DeploymentCallbackFlow.activate(DeploymentCallbackFlow.java:71) at weblogic.application.internal.flow.DeploymentCallbackFlow.activate(DeploymentCallbackFlow.java:63) at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:635) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:212) at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:154) at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80) at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:566) at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:136) at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:104) at weblogic.deploy.internal.targetserver.operations.StartOperation.doCommit(StartOperation.java:139) at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:320) at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:816) at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1223) at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:434) at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:161) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:12) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:67) at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:464) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200) at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
    Thank's for your help.
    Thomas

    I am facing a new problem, i tried to create the folowing build script:
    <project default="build_artefacts">
         <taskdef name="apt" classname="com.sun.tools.ws.ant.Apt">
              <classpath refid="jaxws.classpath" />
         </taskdef>
         <target name="compile-server">
              <echo message="Compiling server classes" />
              <javac destdir="target/classes" includes="**/com/**">
                   <src path="com/b2winc/controlpanel/business/facade/customer" />
                   <classpath refid="project.classpath" />
              </javac>
         </target>
         <target name="apt" depends="compile-server">
              <apt destdir="${build}" sourcedestdir="${generated}" sourcepath="${src}">
                   <classpath refid="jaxws.classpath" />
                   <source dir="${src}">
                        <include name="**com/b2winc/controlpanel/business/*.java" />
                   </source>
              </apt>
         </target>
         <target name="build_artefacts" depends="apt">
              <echo message="${src}"></echo>
              <taskdef name="antwsgen" classname="com.sun.tools.ws.ant.WsGen"
                   classpath="${src}jaxws/lib/jaxws-tools.jar" />
              <antwsgen
                   sei="CustomerFacade" verbose="true"
                   destdir="target/classes" sourcedestdir="target/temp" >
                   <classpath path="jaxws.classpath"/>
              </antwsgen>
         </target>
         <path id="jaxws.classpath">
              <pathelement path="jaxws-ri-121/lib/jaxws-tools.jar" />
              <pathelement path="jaxws-ri-121/lib/jaxb-api.jar" />
              <pathelement path="jaxws-ri-121/lib/jaxb-impl.jar" />
              <pathelement path="jaxws-ri-121/lib/jaxws-api.jar" />
         </path>
    </project>     I used this guideline: http://today.java.net/pub/a/today/2006/06/13/web-services-with-jax-ws-2.0.html
    And i get the following error:
          [apt] An exception has occurred in apt (1.5.0_11). Please file a bug at th
    e Java Developer Connection (http://java.sun.com/webapps/bugreport)  after check
    ing the Bug Parade for duplicates. Include your program and the following diagno
    stic in your report.  Thank you.
          [apt] java.lang.NoClassDefFoundError: com/sun/mirror/apt/AnnotationProcessorFactoryThe strange thing, that this class belongs to the tools.jar inside my JDK 5.
    Thanks
    Carlos

  • Transaction management in stateless session beans.

    Hi all,
    I am using EJB 1.1.
    I have a statless session bean that has two methods- A and B.
    which does not involve any database interaction
    like inserting/updating/deleting the data in the database.
    The process flow is such the client always calls A first followed by the call to B.
    I have the Transaction attribute set as TX_REQUIRED at the whole bean level.
    Now my question is as follows:
    Since it is a stateless bean, ejbCreate() is called for every method's invocation.
    So does it mean that a new transaction is started for every method invocation?
    Also since a transaction ends by commit/rollback.
    The transation associated with the method A/B will never get completed as there is no commit/rollback involved in method implementation.
    So how is this transaction ended?
    Any more details about the transaction management in stateless session beans is highly appreciated.
    Any input at the earliest is highly appreciated.
    Thanks in advance.

    Since it is a stateless bean, ejbCreate() is called for every method's invocation.For stateless session bean , Create() is not delegated to the instance.
    So does it mean that a new transaction is started for every method invocation?This depends opon the Tx attribute and sequence of calls. Since you have given Tx_required then if you call any method and there is no Tx context associated with client,then a new TX will be started by container othere wise it will execute in the same TX context as the calling client. Note that client can be jsp or other ejb method.
    Also since a transaction ends by commit/rollback.
    The transation associated with the method A/B will never get completed >as there is no commit/rollback involved in method implementation.
    So how is this transaction ended?If you are using COntainer managed TX then Transaction handling like starting , ending etc is handled by the container. You need not worry about that.
    Any more details about the transaction management in stateless session >beans is highly appreciated.
    Any input at the earliest is highly appreciated.Some time back I had read the article on how the Transaction management done by container on IBM Site. I dont have URL , but you can search the site.
    HTH
    -Ashwani

  • Javax ejb CreateException: Could not create stateless EJB

    Hi,
    I have a JavaEE (EJB3.0) project deployed on glassfish2.1 as -.ear (exported from eclipse3.4 to the autodeploy-folder) with -.ejb.jar, -.webui.war, general-lib-base.jar (some other...)
    The session bean is invoked by a jsf-managed bean. Have a pure annotation +@ejb+ in managed bean (identifiing the ejb-interface (+@Remote+) ...the ejb is annotated with +@stateless+
    get the following error message:
    *...nested exception is: javax.ejb.CreateException: Could not create stateless EJB*
    as beginner in the JavaEE-field I'm looking for some help concerning the possible causes.
    thank's for any comment...
    (also posted in the Enterprise JavaBeans-forum possibly better there)

    problem fixed: in the deployment-descriptor ejb-jar.xml a spezification of the session-bean hung around ...very annoying!

  • Global transactions in OSB and EJB 2.1

    Hi,
    My team is working in a SOA service based on OSB 11g (11.1.1.5) using DB JCA Adapter and EJB 2.1 over WLS 10g(WLI environment). The logic of the service works in this way:
    1. A table in a database (XE) is polled by the DB Adapter which starts the service (1 row = 1 message).
    2. The message contains a collection of items to be inserted in another Oracle database.
         Once a message/row is picked, and after some steps (logging, validation,etc), there is a for..each action which extracts each item of the collection and executes a service callout action to a business service.
    3. This business service uses EJB protocol to call an EJB (2.1 + WLS Extensions). The EJB is deployed in another domain (WLS 10.3.0/10g and Oracle BEA drivers)  and only executes an store procedure with the parameters based on the message and inserts these values in a table.
    4. Once the for...each finishes, there is a call to another proxy service which marks the message/row as "processed" in the source table. This update is done via DB JCA also.
    5. In case of an error, the error handler of the proxy service calls the proxy service mentioned above to mark the row as "Failed" (in fact there is a retry mechanism, but it's not important for now).
    The service requires to work inside a global transaction. The main requirement is that the collection of items should be processed as "All or None", so basically we're using the options to manage the global transaction. However, the problem is that it's failing to rollback the whole insertion of items when an error is simulated. It only rolls back the last insertion/execution of SP.
    Additionally, the proxy service that should mark the row as FAILED, never updates this one, and the tables stay locked until we modify one of the store procedure in order to avoid the simulated error and commit the transaction.
    The EJB uses WLS extensions with the annotations to "transaction required". The proxy service has the option transaction required also. The database drivers are all XA and we're testing against Oracle11g XE (however, the EJB destiny will be Oracle 8i in production).
    We have tried different alternatives, splitting the logic in different proxies (Proxy services for JCA, Proxy with For Each for EJB, etc), isolating the specific part with the EJB call, without success.
    The security between domains is set as Global Trust.
    Do you have any idea, example or suggestion about this problem? Is EJB really supported in Global Transactions and XA?
    Thanks in advance.

    where do you find the J2EE Connector 1.5 compliant
    Resource Adapter?I wrote the compliant adapter myself. Hey Steve,
    Were you able to find a solution for this problem. I am struggling with the same problem with the RI Beta implementation.
    Sandeep

  • Problem catching handle ejb session in jsp pages

    Hello,
    i'm trying to develop an ejb application.
    I have created an ejb session stateful in a second ejb stateless :
    InitialContext ic = new InitialContext();
    UserSessionHome home = (UserSessionHome)ic.lookup("UserSessionHome");
    UserSession conn = home.create(login,mdp);
    Then I have to retrieve this ejb session stateful in a jsp page in order to remove it or to call some others functions developped in the bean interface.
    I think that the solution for this problem are the ejb handles.
    But i don't know how and where I can store them.
    Can you help me?
    Thanx
    Sophie

    You put them in the HttpSession. For "how," read the API docs.

  • A Major Transaction Problem!

    "A" is a record which has already been inserted into a table(TBL).
    "insert(Y)" is a method that inserts a given record -Y- into TBL.
    "foo(X)" is a method that takes a record as a parameter and queries it on a view(VIEW). This view is a
    huge select statement that selects from TBL.
    Here is the problem:
    insert(B);
    foo( A ); /* returns true */
    but
    insert(B); /* B does not exist in TBL */
    foo(B); /* returns false and catches an exception that "A" is not found! */
    insert(Y) method is a CMP EJB method but foo(X) uses JDBC to access DBMS.
    so what can cause this transaction problem?
    thanks in advance,
    -selcuk

    Hi,
    Maybe foo is running in a different transaction than insert?
    Some possible causes:
    -you are starting a new transaction for foo, either via the UserTransaction or via REQUIRES_NEW
    -you are using a regular JDBC driver for foo instead of an XADataSource.
    Did you try to set foo's transaction attribute to REQUIRED?
    Best,
    Guy
    http://www.atomikos.com

  • Stateless EJB blocks

    Hi.
    I've an stateless ejb that calls another stateless ejb. The two EJB's use Entity Beans though the database schema is different.
    Here's the snippet of code:
        public Libro insertarLibro( String codigo,
                                    Long ejemplar,
                                    Calendar dataPublicacion,
                                    String isdn,
                                    String titulo,
                                    String cifEditorial,
                                    String nifAutor) throws SGLException,
                                                           StockException,
                                                           Exception {
            ServiceFacade01EJBClient externalSystemProxy = new ServiceFacade01EJBClient();                                                      
            StockFacadeEJB stockFacade = SglServiceLocator.getInstance().getStockFacadeEjb();
            stockFacade.addBook(getLibroDto(libro));
            em.persist(libro);
            em.getTransaction().commit();
            return libro;
        }The problem is that the blocking is random. Sometimes it blocks in this line:
    stockFacade.addBook(getLibroDto(libro));
    Other times it returns normally but then blocks (I use JDeveloper).
    The odd thing is that sometimes the data is written in the database. Other times not.
    On the called ejb the data is always written. But on the caller the data is not written.
    I'm using same database instance but different users/schemas for the two stateless EJB's.

    Or is it becoz the two methods that it objected to were returning user-defined objects and not String, void, Integer ... that a web service can recognize !
    But still ... why cannot it just ignore the methods that are not exposed ?
    Can someone throw some light on this.
    Thanks,
    Krishna

  • Error with stateless EJB

    Hi,
    I am new to WebLogic and I trying to learn it. I was doing an exercise with a stateless EJB I got from a book and get this error:
    javax.naming.NoInitialContextException: Cannot instantiate class: weblogic.jndi.WLInitialContextFactory. Root exception is java.lang.ClassNotFoundException: weblogic.jndi.WLInitialContextFactory
         at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
    That class is already in my class path and still does not work. I am using WLS 8.1 on a Linux Suse 9.0 OS, and my IDE is Eclipse. The code seems to be fine seems it is deployed flawlessly by the server. No errors, no warnings. I can post if some one needs to see it. Any ideas?
    Thanks!

    If anyone is interested, and since it seems to be a common anoying problem, the solution is to put the weblogic.jar files in the classpath, and all of the client ones as well.

  • Cloudscape transaction problem. Please help.

    Hi,
    from EJB A in application x I call a method in EJB V in application Y.
    The application use different databases in the same Cloudscape server.
    Both beans have container managed transaction.
    I'm getting the following exception:
    javax.ejb.TransactionRolledbackLocalException: Exception thrown from bean;
    nested exception is: javax.ejb.EJBException: nested exception is:
    java.sql.SQLException: java.lang.IllegalStateException: Local transaction
    already ha
    javax.ejb.EJBException: nested exception is: java.sql.SQLException:
    java.lang.IllegalStateException: Local transaction already has 1 non-XA
    Resource: cannot add more resources
    java.sql.SQLException: java.lang.IllegalStateException: Local transaction
    already has 1 non-XA Resource: cannot add more resources
    If I set the trans attribute of the calling method to 'Never' it works fine but
    then I do not have transactions any more. Does cloudscape only allow on
    transaction running? What's the problem here?
    TIA
    Frank

    Hi,
    thanx for that. I was wondering what that XACloudscape is all about.
    Can you tell me what I have to do if I want to use XACloudscape?
    Right now I use this configuration:
    jdbcDataSource.5.name=jdbc/Standort1
    jdbcDataSource.5.url=jdbc\:cloudscape\:rmi\:Standort1;create\=true
    jdbcDataSource.6.name=jdbc/Standort2
    jdbcDataSource.6.url=jdbc\:cloudscape\:rmi\:Standort2;create\=true
    jdbcDataSource.7.name=jdbc/Standort3
    jdbcDataSource.7.url=jdbc\:cloudscape\:rmi\:Standort3;create\=true
    jdbcDataSource.8.name=jdbc/Zentrale
    jdbcDataSource.8.url=jdbc\:cloudscape\:rmi\:Zentrale;create\=true
    using the corresponding JNDI names during deployment.
    I am using J2EE RI 1.3.1 with Cloudscape DB.
    Would be great to get a little hint.
    TIA
    Frank

Maybe you are looking for