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

Similar Messages

  • A question about entity manager in stateless session bean.

    JSR 220 ejbcore, page 47 : stateless session bean: All business object references of the same interface type for the same stateless session bean have the "same object identity", which is assigned by the container.
    So, if we have two session beans in client code...
    @EJB Cart cart1;
    @EJB Cart cart2;
    then cart1.equals(cart2)==true
    If we declare entity manager in stateless session bean:
    @PersistenceContext( unitName="ds" ,type=PersistenceContextType.TRANSACTION)
    private EntityManager em;If cart1 and cart2 are the same reference, do we have any problem when using the same reference(maybe the same em? ) to get data from db?

    If cart1 and cart2 are the same reference, do we have
    any problem when using the same reference(maybe the
    same em? ) to get data from db?No. In EJB, there is a distinction between the EJB reference and the bean instance.
    Each time you make an invocation on an EJB reference for a stateless session bean,
    the container can choose any instance of that bean's bean class to process the
    invocation. That's true whether you invoke the same reference multiple times or
    two difference references to the same bean.
    Each bean instance is guaranteed to be single-threaded.

  • Transaction Management -  App Module in Stateless Session Bean

    Hi All,
    We are using Application Module in local mode in a Stateless Session Bean. The application module gets the database connection from the datasource of the application server(Oracle 9iAS).
    The problem that we are facing is as follows
    - When a database update/insert is made using the Application Module and the ViewObject (and the underlying Entity Object), the changes are not being commited.
    Please note that we are not using the ApplicationModule.getTransaction.commit() as it does not give us commit/rollback control from another Session Bean/UseCase. We instead are relying on the Container to manager the transaction and commit the database changes. But the container does not seem to refresh the changes to the database.
    Q1 - Is there a contract between the container and the application module that needs to be created so that the container managed-transaction and the application module work together ?
    Any help in this matter would be greatly appreciated.
    -Ankur Sinha

    Q1 - Is there a contract between the container and the application module that needs to be created so that the container managed-transaction and the application module work together ?For stateless beans you have to call postChanges in the business method for the changes to be applied to the db. For stateful beans bc4j we do that automatically just before the transaction ends.
    Take a look at the following howto
    http://otn.oracle.com/products/jdev/howtos/bc4j/ejbstateless_with_bc4j.html
    In 9.0.3 you'll be able to create a stateless service bean declaritively.
    dhiraj Hi dhiraj,
    - I looked at the example but was not able to find the ContainerManagedTxnHandlerImpl class in the BC4J jars. Can you point me to the latest version of BC4J on technet ?. I already have JDeveloper 9.0.2
    - Regarding your response, what do you mean by creating stateless service bean declaritively ?
    Thanks,
    Ankur

  • EJB Stateless Session Bean Transactions

    I have a stateless session bean.
    Its deployment descripter references a JDBC DataSource.
    It uses container managed transactions.
    If I make JDBC calls, within a business method
    of this stateless session bean, with the referred datasource, is it attached
    to a container managed transaction?

    If I make JDBC calls, within a business method
    of this stateless session bean, with the referred
    datasource, is it attached
    to a container managed transaction?IIRC, yes. For CMT, the container will roll back any JDBC actions carried out by a method if it fails.

  • 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 is not Rolling Back in Stateless Session Bean

              Hi,
              I am using UserTransaction in Stateless Session bean .
              Transaction is not rolling back.
              The following code is writen in stateless session bean. In UserTransaction i am
              calling Two methods of another stateless session bean.
              The problem is if doJob2() method fails, doJob1() method is rolling back. These
              two methods consist of SQL statement with different Connection Object from TXDataSource.And
              session bean(TestSession) is set to CMT, attribute as "Required".
              try{
              Context ictx=new InitialContext();
              TestHome home=(TestHome)ictx.lookup("TestSession");
                   utx = sessionCtx.getUserTransaction();
                   utx.begin();
              TestRemote remote=home.create();
                   remote.doJob1();
                   remote.doJob2();
                   utx.commit();
              }catch(Exception e)
                   try{
                   utx.rollback();
              }catch(Exception ex)
                   System.out.println("unable to rollback"+ex);
              if any SQL Exception as occured in doJob2(), its calling method utx.rollback()
              in catch block. but SQL statements executed thru. doJob1() are not rolling back.
              what might be the reason?
              thanks
              Ranganath
              

              Thanx Priscilla ,
              Transaction is working.
              ranganath
              "Priscilla Fung" <[email protected]> wrote:
              >
              >In your ejb-jar.xml, you should specify <transaction-type> element to
              >be "Container"
              >for container-managed transaction. If you specified it to be "Bean" for
              >bean-managed
              >transaction, EJB ontainer will suspend the caller's transaction before
              >starting
              >a new transaction for your doJobX() methods. Thus, doJob1()nd doJob2()
              >will be
              >executing in different transactions, and thus rolling back doJob2()'s
              >transaction
              >will have no effect on work done and committed in doJob1()'s transaction.
              >
              >Regards,
              >
              >Priscilla
              >
              >
              >"Ranganath" <[email protected]> wrote:
              >>
              >>
              >>
              >>I am sending config.xml,deployment descriptors, code snippet for TestSession.
              >>i
              >>am using weblogic6.0sp2.
              >>if you need any aditional info. please let me know.
              >>
              >>thanks
              >>ranganath
              >>
              >>EJB-JAR.xml
              >>
              >><?xml version="1.0"?>
              >>
              >><!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
              >JavaBeans
              >>1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'>
              >>
              >><ejb-jar>
              >>     <enterprise-beans>
              >>     <session>
              >>          <ejb-name>TestSession</ejb-name>
              >>          <home>com.apar.sslbridge.test.TestHome</home>
              >>          <remote>com.apar.sslbridge.test.TestRemote</remote>
              >>          <ejb-class>com.apar.sslbridge.test.TestBean</ejb-class>
              >>          <session-type>Stateless</session-type>
              >>          <transaction-type>Bean</transaction-type>
              >>          <resource-ref>
              >>     <res-ref-name>jdbc/oraclePool</res-ref-name>
              >>     <res-type>javax.sql.DataSource</res-type>
              >>     <res-auth>Container</res-auth>
              >>          </resource-ref>
              >>     </session>
              >>     </enterprise-beans>
              >>     <assembly-descriptor>
              >>     <container-transaction>
              >>          <method>
              >>          <ejb-name>TestSession</ejb-name>
              >>          <method-intf>Remote</method-intf>
              >>          <method-name>*</method-name>
              >>          </method>
              >>          <trans-attribute>Required</trans-attribute>
              >>     </container-transaction>
              >> </assembly-descriptor>
              >></ejb-jar>
              >>
              >>
              >>TestSession CODE:
              >>
              >>
              >>     public void doJob1() throws RemoteException
              >>     {
              >>     Statement st = null;
              >>     String query=null;
              >>     try{
              >>     con=getConnection();
              >>     st=con.createStatement();
              >>     query="insert into x values("+x+++")";
              >>     System.out.println(query);
              >>     int rec=st.executeUpdate(query);
              >>     }catch(SQLException sqle)
              >>     {
              >>     System.out.println("SQL Exception "+sqle);
              >> throw new RemoteException("RemoteException*****SQLError");
              >>     } catch (Exception e) {
              >>     System.out.println("Exception "+e);
              >> throw new RemoteException("RemoteException*****GenralError");
              >> }
              >>}
              >>
              >>
              >> public void doJob2()throws RemoteException
              >> {
              >> Connection con=null;
              >> Statement st = null;
              >> String query=null;
              >> try{
              >> con=getConnection();
              >> st=con.createStatement();
              >> query="insert into y values("+x+++")";
              >> System.out.println(query);
              >> int rec=st.executeUpdate(query);
              >> }catch(SQLException sqle)
              >> {
              >> System.out.println("SQL Exception "+sqle);
              >> throw new RemoteException("RemoteException*****SQLError");
              >> } catch (Exception e) {
              >> System.out.println("Exception "+e);
              >> throw new RemoteException("RemoteException*****GenralError");
              >>}
              >>}
              >>private Connection getConnection(){
              >>try {
              >>Connection con = StaticParams.POOL_DATASOURCE.getConnection();
              >>return con;
              >>     } catch(Exception e) {
              >>     System.out.println("TestBean.getConnection() Unable to get get pool
              >>connection
              >>" + e);
              >>     }
              >>}
              >>
              >>
              >>
              >>
              >>"Priscilla Fung" <[email protected]> wrote:
              >>>
              >>>It should work if you are using TxDataSource. Could you post your
              >config.xml,
              >>>deployment descriptors, code snippet for TestSession?
              >>>
              >>>Regards,
              >>>
              >>>Priscilla
              >>>
              >>>"Ranganath" <[email protected]> wrote:
              >>>>
              >>>>Hi,
              >>>>
              >>>> I am using UserTransaction in Stateless Session bean .
              >>>> Transaction is not rolling back.
              >>>>
              >>>>The following code is writen in stateless session bean. In UserTransaction
              >>>>i am
              >>>>calling Two methods of another stateless session bean.
              >>>> The problem is if doJob2() method fails, doJob1() method is rolling
              >>>> back. These
              >>>>two methods consist of SQL statement with different Connection Object
              >>>>from TXDataSource.And
              >>>>session bean(TestSession) is set to CMT, attribute as "Required".
              >>>>
              >>>> try{
              >>>> Context ictx=new InitialContext();
              >>>> TestHome home=(TestHome)ictx.lookup("TestSession");
              >>>>     utx = sessionCtx.getUserTransaction();
              >>>>     utx.begin();
              >>>> TestRemote remote=home.create();
              >>>>     remote.doJob1();
              >>>>     remote.doJob2();
              >>>>     utx.commit();
              >>>> }catch(Exception e)
              >>>> {
              >>>>     try{
              >>>>      utx.rollback();
              >>>> }catch(Exception ex)
              >>>> {
              >>>>     System.out.println("unable to rollback"+ex);
              >>>>     }
              >>>> }
              >>>>if any SQL Exception as occured in doJob2(), its calling method utx.rollback()
              >>>>in catch block. but SQL statements executed thru. doJob1() are not
              >>rolling
              >>>>back.
              >>>>what might be the reason?
              >>>>
              >>>>thanks
              >>>>Ranganath
              >>>
              >>
              >
              

  • Transactional error when using JMS from stateless session bean

    I get a transaction exception when committing a bean method responsible for sending to a JMS topic. This happens only occasionally when two separate threads invoke this method "at the same time".
    The scenario:
    Two separate threads running two different instances of a stateless session bean (slsb A). This ejb (slsb A) has an injected slsb B which is communicating with the the topic.
    Both instances of slsb A are utilising the same instance of slsb B.
    The CMT transactions for the two threads start in slsb A from methods with transaction attribute "RequiresNew". All nested methods are to other slsbs and have the transaction attribute "Required". The method in slsb B which sends the message is closing both the session and the connection to the topic.
    I'm running Glassfish version 9.1_02 (build b04-fcs) and JMS implementation OpenMQ version 4.1.
    Stacktrace (glassfish log):
    [#|2008-09-09T13:00:40.515+0200|SEVERE|sun-appserver9.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=108e8418-71a6-4d8b-a94d-9e1edc885891;|commitTransaction (XA) on JMSService:jmsdirect failed for connectionId:5754505514139844608 and onePhase:false due to unkown JMSService server error.|#]
    [#|2008-09-09T13:00:40.515+0200|SEVERE|sun-appserver9.1|javax.enterprise.system.core.transaction|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;org.omg.CORBA.INTERNAL:   vmcid: 0x0  minor code: 0 completed: Maybe;commit;_RequestID=108e8418-71a6-4d8b-a94d-9e1edc885891;|JTS5031: Exception [org.omg.CORBA.INTERNAL:   vmcid: 0x0  minor code: 0 completed: Maybe] on Resource [commit] operation.|#]
    [#|2008-09-09T13:00:40.531+0200|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;SubscriptionBean;|EJB5018: An exception was thrown during an ejb invocation on [SubscriptionBean]|#]
    [#|2008-09-09T13:00:40.531+0200|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;|
    javax.ejb.EJBException: Unable to complete container-managed transaction.; nested exception is: javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL:   vmcid: 0x0  minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
    javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL:   vmcid: 0x0  minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
         at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:321)
         at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
         at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
         at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
         at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3585)
         at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
         at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
         at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
         at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
         at $Proxy130.requestNewSubscription(Unknown Source)
         at com.abeldrm.kms.core.services.subscription.SubscriptionWSBean.requestNewSubscription(SubscriptionWSBean.java:94)
         at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
         at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
         at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
         at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
         at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
         at $Proxy129.requestNewSubscription(Unknown Source)
         at sun.reflect.GeneratedMethodAccessor126.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81)
         at com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
         at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
         at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
         at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
         at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
         at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
         at com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java:329)
         at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
         at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
         at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
         at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
         at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
         at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
         at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
         at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
         at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:226)
         at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
         at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
         at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
         at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
    IMQ broker log:
    [09/Sep/2008:13:00:40 CEST] ERROR CommitTransaction: commit failed. Connection ID: 5754505514139844608, Transaction ID: 0:
    com.sun.messaging.jmq.jmsserver.util.BrokerException: Unknown Transaction 0
         at com.sun.messaging.jmq.jmsserver.data.protocol.ProtocolImpl.commitTransaction(ProtocolImpl.java:630)
         at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.commitTransaction(IMQDirectService.java:1735)
         at com.sun.messaging.jms.ra.DirectXAResource.commit(DirectXAResource.java:201)
         at com.sun.jts.jtsxa.OTSResourceImpl.commit(OTSResourceImpl.java:114)
         at com.sun.jts.CosTransactions.RegisteredResources.distributeCommit(RegisteredResources.java:795)
         at com.sun.jts.CosTransactions.TopCoordinator.commit(TopCoordinator.java:2111)
         at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:403)
         at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:249)
         at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
         at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
         at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
         at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
         at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
         at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3585)
         at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
         at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
         at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
         at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
         at $Proxy130.requestNewSubscription(Unknown Source)
         at com.abeldrm.kms.core.services.subscription.SubscriptionWSBean.requestNewSubscription(SubscriptionWSBean.java:94)
         at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
         at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
         at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
         at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
         at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
         at $Proxy129.requestNewSubscription(Unknown Source)
         at sun.reflect.GeneratedMethodAccessor126.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81)
         at com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
         at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
         at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
         at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
         at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
         at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
         at com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java:329)
         at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
         at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
         at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
         at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
         at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
         at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
         at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
         at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
         at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:226)
         at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
         at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
         at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
         at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
    Have anyone any idea why this should fail?
    Regards,
    Jon

    I would suggest opening a case with [email protected] FWIW, I recall seeing
              something like this in WLS 6.0. I believe it is fixed in WLS 6.1
              -- Rob
              Chris Dupuy wrote:
              > Btw, this occurs when I create an stateful session bean that ends up
              > throwing an exception and setRollbackOnly() is called. From that point
              > forward, my logs fill with this message.
              >
              > Chris
              >
              > "Chris Dupuy" <[email protected]> wrote in message
              > news:[email protected]..
              > > anyone know what this means, and what you can do about it?
              > >
              > >
              > > <Error> <ConnectionManager> <atossd03> <cbeyondServer> <ExecuteThread:
              > '14'
              > > for queue: 'd
              > > efault'> <> <> <000000> <Closing:
              > 'weblogic.rjvm.t3.T3JVMConnection@488831'
              > > because of: 'Server received a message over an uniniti
              > > alized connection: 'JVMMessage from: 'null' to:
              > >
              > '5825313123619479267S:10.6.6.40:[8000,8000,8001,8001,8000,8001,-1]:cbeyond:c
              > > beyond
              > > Server' cmd: 'CMD_REQUEST', QOS: '101', responseId: '2', invokableId: '1',
              > > flags: 'JVMIDs Not Sent, TX Context Not Sent', abbrev o
              > > ffset: '204'''>
              > >
              > >
              > >
              

  • Transaction can be applied to stateless session bean

    is transaction can be applied to stateless session beanif yes/no why?

    Just because a stateless session bean is stateless doesn't mean it doens't hold state. The stateless means it shouldn't hold any client state.
    It can hold onto for example the dao objects.
    The idea is that you pass all the client state to the sessionbean when calling it.
    Eg.
    public void doBulkOperation( User user ,string param1, String param2){
    operation1( user, param1 );
    operation2( user, param2 );
    public void operation1( User user ,String param1){
    //do some work involving user
    public void operation2( User user ,String param2){
    //do some work involving user
    now suppose that doBulkOperation, operation1, operation2 are declared as transaction required. doBulkOperation starts the transaction if there isn't one running and joins the transaction. Then operation1 and operation2 join in the transaction.
    Perfectly safe!
    What you're not allowed to do is the following:
    privata User user
    public void doBulkOperation( User user ,string param1, String param2){
    this.user = user;
    operation1( param1 );
    operation2( param2 );
    public void operation1( String param1){
    //do some work involving user
    public void operation2( String param2){
    //do some work involving user
    This would be unsafe because concurrent calls will change the user and produce unpredictable results and possibly corrupting data.
    It will work perfectly thougn if there is only one user or you're using a statefull session bean providing you don't share that bean with several clients.

  • Bean-managed stateless session bean can't roll back using JTA

    I use weblogic6.1sp2 + jdk131
    a stateless session bean must do 2 things:
    insert a record to A table and delete another record in A table
    this bean has the same structure as the example in
    j2eetutorial/examples/src/ejb/teller
    I use TxDataSource in weblogic
    if delete fail, the roll back is run,but in database,
    the insert record is STILL in A table.
    any idea?

    make sure that your deployment descriptor says "transaction required".
    Also, If the insert and delete are two different methods, the client must call these two methods in the same transaction scope.

  • Transaction not rolling back in stateless session bean

              Hi,
              I am facing a problem...
              I have one stateless session bean which does multiple updates in SYBASE database.I
              am using non-transactional datasource. Bean calls a method of data access obejct
              whcih internally calls more than one one mehtod to update different tables.If
              any of update fails then I am explicitly thorwing EJBException. Still it is not
              rolling back.
              I have one more application where similar situation is there but only difference
              is that there we have Entity bean and updates are being done through store method.
              In that case with same datasource it is rolling back perfectly.
              I have tried with transactional datasource as well but it didn't work.Then I tried
              to put setAutoCommit(false) in my connection class which gives me connection.But
              then it is not allowing me to enter into my application.
              In deployment descriptor for both the beans transaction attribute is required
              for all methods.
              Regards.
              Rahul.
              

              Hi,
              I am facing a problem...
              I have one stateless session bean which does multiple updates in SYBASE database.I
              am using non-transactional datasource. Bean calls a method of data access obejct
              whcih internally calls more than one one mehtod to update different tables.If
              any of update fails then I am explicitly thorwing EJBException. Still it is not
              rolling back.
              I have one more application where similar situation is there but only difference
              is that there we have Entity bean and updates are being done through store method.
              In that case with same datasource it is rolling back perfectly.
              I have tried with transactional datasource as well but it didn't work.Then I tried
              to put setAutoCommit(false) in my connection class which gives me connection.But
              then it is not allowing me to enter into my application.
              In deployment descriptor for both the beans transaction attribute is required
              for all methods.
              Regards.
              Rahul.
              

  • How to use jta in toplink and stateless session bean EJB 3.0?

    I have an application with techologies jsf,stateless session bean, adf, toplink
    generated by toplink workbench.
    In web side ı want to use two methods in stateless session bean which are updated
    different tables. I call these methods in my page backing bean.
    I also want to JTA in web side. My first methods is done correctly, but second method has an error. I wanto to rollback all transaction.
    How can ı do that? with using JTA in Toplink...

    Yuichi
    Did you manage to solve this?  I'm doing something similar and seeing the same problem, although they're up to 7.3 SP7.
    Any help greatly appreciated.
    Lewis

  • Problem while invoking a Stateless Session bean from another bean

    Hi,
    I have a peculiar problem while coding with Stateless Session beans. Maybe you guys can help me out over here. The scenario is as follows
    There are 3 Stateless Session beans. Let Us say Bean A, B and C. There are three methods, method1, method2, and method3 inside A, B and C respectively.
    From A.method1(), B.method2(), and C.method3() are being invoked sequentially. Each of these methods does some JDBC operation and then returns.
    The problem is this, if C.method3() throws and exception, then I am unable to rollback the changes made by B.method2(). Those changes get "Committed" to the database.
    All the 3 beans have Bean managed persistence property set. I am using WebSphere 6.1.
    Any insight on why this is happening would be greatly appreciated.
    Thanks In Advance
    Amardeep Verma

    Hi,
    This is a matter of calling all three methods in the same transaction context. Most easy way of doing this is having a 4th session bean containing a method calling the other 3. Make sure that the Transaction Attributes are REQUIRED, which is the default.
    If the calls a to different backends/databases, you need global transactions and therefor XA complient database and drivers.
    HTH Robert

  • Would RollBacks For Stateless Session Beans work In case of Stored Procedures or Triggers Written in Oracle PL/SQl

              We are writing a J2EE application and using Weblogic 5.1 on Unix machine. We are
              considering writing some Stored Procedures or Triggers on Oracle DBMS. Hence our
              Stateless Session Beans / Data Access Objects (DAOs) would be calling those stored
              procedures, which would reside on Oracle 8.1.7 (on Windows 2000). (These Data
              Access Objects are running under the umbrella of a Stateless Session Beans). We
              are using WebLogic's Connection Pooling.
              Our question is: Would we get reliable rollbacks from our stored procedures. I
              mean would the Transaction Management process of the EJB container work. Remember
              the SQL is written in the Database (Oracle in this case) in the form of Stored
              Procedures / Triggers through PL/SQL.
              Any ideas or tips would help.
              

              I would agree with Cameron Purdy. Be very cautious to use Oracle specific
              Triggers / Stored Procedures. Consider following, (apart from what he said):
              1. Unreliable behaviour of the Oracle JDBC drivers, specially 8.1.6 family..
              (You may visit the Oracle's web site and see the newsgroups for the JDBC drivers).
              This is enough of a reason to stop right there.
              However for interest sake you may consider following issues:
              2. By use of Oracle specific Triggers / SPs the application will not be portable.
              Vendor Lock In. Remember your choice for J2EE compliant Server (WebLogic in this
              case). The whole purpose would be defeated by going for this option.
              3. There are issues related to the extensibility of the application. I have
              my reservations and would hold my breath on two phase commit protocol transactions
              being reliable in this scenario.
              Have fun...
              Terry
              "Cameron Purdy" <[email protected]> wrote:
              >Yes, the work performed by the SPs and the triggers would be in the same
              >tx.
              >
              >What would NOT work is if the data has been read into WebLogic and then
              >it
              >gets affected by a trigger or SP on the RDBMS, the data in WebLogic is
              >not
              >automatically re-read within that same tx so you need to be careful.
              >
              >Peace,
              >
              >--
              >Cameron Purdy
              >Tangosol Inc.
              >Tangosol Coherence: Clustered Coherent Cache for J2EE
              >Information at http://www.tangosol.com/
              >
              >
              >"Ahmad" <[email protected]> wrote in message
              >news:[email protected]...
              >>
              >> We are writing a J2EE application and using Weblogic 5.1 on Unix machine.
              >We are
              >> considering writing some Stored Procedures or Triggers on Oracle DBMS.
              >Hence our
              >> Stateless Session Beans / Data Access Objects (DAOs) would be calling
              >those stored
              >> procedures, which would reside on Oracle 8.1.7 (on Windows 2000). (These
              >Data
              >> Access Objects are running under the umbrella of a Stateless Session
              >Beans). We
              >> are using WebLogic's Connection Pooling.
              >> Our question is: Would we get reliable rollbacks from our stored
              >procedures. I
              >> mean would the Transaction Management process of the EJB container
              >work.
              >Remember
              >> the SQL is written in the Database (Oracle in this case) in the form
              >of
              >Stored
              >> Procedures / Triggers through PL/SQL.
              >> Any ideas or tips would help.
              >
              >
              

  • TX isolation level with stateless session bean in oc4j

    Hi All,
    I have a stateless session bean with container managed transaction method. This method is called in a Servlet. This method retrieves data from database using 'ejb-location'connection pool and closes the connection inside. Max-connection setting for connection pool is 50
    I am facing a problem running servlet multiple times.
    When i have the tx_attribute as Supports, it works fine. I can run the servlet hundreds of times
    But when i have the tx_attribute as Required, i am able to run servlet only 50 times and further it says 'Max connection limit exceed..unable to get the connection'.
    I assume that with 'Required' attribute, it starts a transaction. Why is the transaction not getting completed at end of method? Is transaction hanging somewhere?
    I assume that i am closing the connection properly as it is working fine with supports attribute.
    When i monitor database, there are only 20 connections.
    Why am i seeing this behaviour?
    Thanks
    srinath

    Hi Deepak,
    Thanks for your reply.
    Actually, our stand alone java application already using spring-hibernate feature. Now we are planning divide our application into modules and deploy each module as ejb beans. As it is already integrated with spring-hibernate we are not using entity beans as of now. My understanding is container uses some default transcation management .so, my question is what are all the configurations needs to be done to let weblogic 10.0 server uses org.springframework.orm.hibernate3.HibernateTransactionManager. I mean, is there are any .xml file in weblogic to configure all these? please reply deepak I am struck here..
    Regards,
    Rushi.

  • Trying to call stateless session bean from MDB

    Folks,
    Am working on RAD and WAS 8.
    I have an MDB. And a stateless session bean (AOBean under EJB project).
    While the listener listens to the messages from queue, it also tries to persist to db. I want to achieve this via a method of AOBean (through instantiating session bean or by injection).
    I have been sucessful by invoking a method from AOBean class -  that method just returns a string (without any objects being passed)
    Problem:
    I am getting IllegalStateException when I try to invoke a method of AOBean class, that has an object as a parameter
    For eg:
    MDB
    @EJB(name="ejb/TransactionMgrAOBean", mappedName="ejb/TransactionMgrAOBean")
    ITransactionMgrAO tranAO;
        public void onMessage(Message message) {
         TextMessage textMessage = (TextMessage) message;
         boolean status = false;
      try {
       TransactionVO tranVO =  getTransactionVO();//Here building the object to be passed to session bean
       String status1  = tranAO.getVersion(tranVO);
      }catch(Exception e){
    AOBean
    @Stateless
    @Remote({ ITransactionMgrAO.class })
    @WebService
    public class TransactionMgrAOBean {
    public String getVersion(TransactionVO tranVO) throws Exception{
      try{
    //business logic 
      } catch(Exception e){
      throw e;
      return true;
    TransactionVO implements Serializable has also inner static classes that are not Serializable.
    EXCEPTION: At runtime we are getting exception saying that the inner classes are not serialized.
    REASON why we are invoking session bean from MDB? We found that if we invoke any service from AOBean the transaction management was successful. We are using sessionContext.setRollBackonly when an exception occurs. Tranasactions are not rolled back when any db exception occurs if we invoke business logic methods from Model layer of another NON-EJB package.
    Hope I have provided enough information!

    My concret problem is that I want to call an ejb session contained in an ejb project from a session bean in a different web project. When I include the code in my web session bean I get the error adjunted:
    - Code:
    @EJB
    private UserRemote userSessionBean;
    - Error:
    Exception Details: javax.naming.NameNotFoundException
    pac.UserRemote#pac.UserRemote not found
    Possible Source of Error:
    Class Name: com.sun.enterprise.naming.TransientContext
    File Name: TransientContext.java
    Method Name: doLookup
    Line Number: 216
    Any suggestion?

Maybe you are looking for

  • TS1292 The content code Apple sent me to download mountain lion for free is invalid.

    I was trying to download mountain lion for free on my mbair, but the code Apple sent me is invalid.  Any ideas on how to resolve it?

  • Converting Flash Catalyst FXP File into HTML

    Hey there Adobe Community, We have a client who's website we built quite a while ago in Flash Catalyst, the problem is as many of you know that Flash Catalyst has been discontinued. Does anyone know of any way to get our FXP File converted into HTML?

  • Lost EMCTL in Application Server Home in Solaris 10

    I have lost my emctl file for Grid Control in the appplication server home for Solaris 10 . Can someone please please help me by posting a version of it so that I can then just add my paths to it . Thanks a bunch

  • Fixed width for posts

    Hi, I have trouble reading some posts of users since the width of the HTML table displaying the post displays parts of it outside my 1024x768 display. I bet I am not the only one with this issue. So far I have found the problem only if users are post

  • Exception : Type does not exist

    Hello, I have imported a model into my webdynpro (without any errors), binded it with the component controller and when i try to deploy my application, i get the following exception: com.sap.dictionary.runtime.DdException: Type de.cideon.models2.plma