Transaction management in EJB

Suppose, a method in session bean is called that deals with some entity beans. I want to maintain transaction over some block of codes separately (e.g. History table has to be updated synchronously with the master table) not over the whole things in the method. How it can be done?

Hi Kuntal,
BMP/CMP and BMT/CMT are completely different. BMP/CMP (Bean-managed persistence/ Container-managed persistence) describes the way in which entity bean persistence is handled.
BMT/CMT (Bean-managed transactions / Container-managed transactions) controls whether bean developer or the container is in charge of demarcating transactions.
Entity beans can be either BMP or CMP. However, they always have CMT. It's not possible to use UserTransaction wtihin an entity bean.
For session beans, you can use BMT and use the session bean as a facade to access your entity beans. That would give you the control you're looking for.

Similar Messages

  • Ejb transaction management jndi lookup name problem

    Hi everyone
    i want to use usertransaction object.
    İ called it with jndi name like UserTransaction tran = (UserTransaction) ctx.lookup("java:comp/UserTransaction");
    But there are many exception occur.
    Exception in thread "main" java.lang.NoClassDefFoundError: org/netbeans/modules/schema2beans/BaseBean
         at java.lang.ClassLoader.defineClass1(Native Method)
         at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
         at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
         at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
         at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
         at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
         at java.lang.ClassLoader.defineClass1(Native Method)
         at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
         at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
         at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
         at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
         at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
         at com.sun.enterprise.admin.event.AdminEventListenerRegistry.addEventListener(AdminEventListenerRegistry.java:262)
         at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.<clinit>(J2EETransactionManagerImpl.java:1404)
         at com.sun.enterprise.distributedtx.UserTransactionImpl.init(UserTransactionImpl.java:119)
         at com.sun.enterprise.distributedtx.UserTransactionImpl.<init>(UserTransactionImpl.java:101)
         at com.sun.enterprise.distributedtx.UserTransactionImpl.<init>(UserTransactionImpl.java:92)
         at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.java:194)
         at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:407)
         at javax.naming.InitialContext.lookup(InitialContext.java:392)
         at org.columbus.teien.entities.Deneme.main(Deneme.java:42)
    Caused by: java.lang.ClassNotFoundException: org.netbeans.modules.schema2beans.BaseBean
         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
    My session beans are stateless and i use container-managed transaction management(cmt)
    And my application server is glassfish 2.1
    How can i use this problem.
    Thanks for your reply.

    Do you have org.netbeans.modules.* classes referenced in your code?
    Those IDE classes are (correctly) not available on your container so you should consider not using them in your code.

  • How to use application managed entity manager in EJB?

    I finish reading The EntityManager Interface in JEE tutorial.
    I know I can use container manager entity manager in EJB, but I want to explore how to use application managed entity manager in EJB.
    Can I use application managed entity manager in EJB (container management JTA transaction is used)? Where do I should close entity manager if can?
    The following is an example from JEE tutorial, but didn't find where to calose entity manager. and can I create mutiple EntityManagerFactory objects and Entity Manager objects to use them in a JTA transaction?
    @PersistenceUnit
    EntityManagerFactory emf;
    EntityManager em;
    @Resource
    UserTransaction utx;
    em = emf.createEntityManager();
    try {
      utx.begin();
      em.persist(SomeEntity);
      em.merge(AnotherEntity);
      em.remove(ThirdEntity);
      utx.commit();
    } catch (Exception e) {
      utx.rollback();

    Seems like a very poor example, the whole power of EJBs is to use Container Managed Transactions so you don't NEED to manage the transaction and the entity manager yourself. What you posted is code I would expect in a non-JEE application, or in a piece of code which requires fine-tuned transaction boundaries such as batched data importing logic.
    If I were you I'd research JPA in steps.
    a) learn about JPA as an API outside of the scope of EJBs (recommended reading: the book 'Pro JPA 2')
    b) learn about Container Managed Transactions in EJBs
    c) learn about Bean Managed Transactions in EJBs
    Right now you're rushing into c). I can understand that it raises many question marks at this point.

  • 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

  • Configuration for Transaction Management

              Hi,
              I am working with Weblogic Server SP1. I am facing a problem in configuring for
              Transaction Management.
              I have a session EJB say SEJB and two entity EJB say EEJB1 and EEJB2. EEJB1 is
              for the parent table
              and EEJB2 is for the child table.
              I have two records in the database REC1 and REC2.
              REC2 has dependencies and cannot be deleted, while REC1 can be deleted.
              In weblogic-ejb-jar.xml I have configured as follows:
              <weblogic-enterprise-bean>
              <ejb-name>SEJB</ejb-name>
              <stateless-session-descriptor>
              <pool>
              <max-beans-in-free-pool>300</max-beans-in-free-pool>
              <initial-beans-in-free-pool>150</initial-beans-in-free-pool>
              </pool>
              </stateless-session-descriptor>
              <reference-descriptor>
                   <ejb-reference-description>
                   <ejb-ref-name>EEJB</ejb-ref-name>
                   <jndi-name>EEJBean</jndi-name>
                   </ejb-reference-description>
                   </reference-descriptor>
              <jndi-name>SEJBn</jndi-name>
              </weblogic-enterprise-bean>
              Further, in ejb-jar.xml I have set up the <trans-attribute> as RequiresNew for
              Session Bean while Supports
              for the EEJB. Something like this:...
              <container-transaction>
              <method>
              <ejb-name>SEJB</ejb-name>
              <method-intf>Remote</method-intf>
              <method-name>*</method-name>
              </method>
              <trans-attribute>RequiresNew</trans-attribute>
              </container-transaction>
              In spite of this setting, when, through the client, I am selecting the two records
              REC1 and REC2 at the same
              time and deleting them, REC1 gets deleted while REC2 does not and gives a TransactionRollbackException.
              Ideally, since both are part of a single transaction, both should have been rolled
              back.
              Please suggest if I am missing on some kind of configuration parameter or setting.
              I'll be more than
              happy to provide some more details to get the problem solved.
              I can also be reached at [email protected]
              Thanks in advance,
              Regards,
              Rishi
              

    TCode: SWF5
    Enterprise_Extensions:
    -> EA-FS
    Enterprise_Business_Functions:
    -> FIN_TRM*
    Rg
    Lorenz

  • @TransactionAttribute annotation being ignored by Transaction Manager

    I am currently running jboss-4.0.4GA. I believe I must have something configured incorrectly, or I misunderstand transaction management performed by the container. Though I have my datasource declared as local-tx, which I believe allows transactions, it appears that my a call to a remote function in a stateless session bean is completely executed in one single transaction, regardless of the @TransactionAttribute tags.
    In my example, I call a function with @TransactionAttribute = REQUIRED. This is the OUTER FUNCTION. This function inserts a record into the cust table of our database. Then this function calls a second function with @TransactionAttribute = REQUIRES_NEW. This is the INNER FUNCTION.
    This function should, according to spec, start up a new transaction independant of the first function. However, the INNER function can select the (un-committed) cust record from the OUTER function. The INNER function then proceeds to add a cust record of its own to the database.
    Control then returns to the OUTER function, which can succesfully read the cust record inserted by the INNER function, which is to be expected because the INNER function should have had its transaction committed. However, my program then throws a RuntimeException in order to force a rollback, and this rollback removes both the cust record inserted by the OUTER function and the cust record inserted by the INNER function.
    To further my belief that the transaction manager is ignoring my @TransactionAttribute annotations, I change the TransactionAttributeType of the INNER function to "NEVER". According to spec, the code should throw an exception when this function is called within a managed transaction. However, when I run the code I get the exact same behavior as when the INNER function is "REQUIRES_NEW".
    I would greatly appreciate if anyone has any insight into what I am doing wrong. Thanks!
    Client Program that Invokes TestTransImpl Stateless Session Bean
    public class Client{
         public static void main(String[] args) throws Exception {
              try{               
                   Properties env = new Properties();
                               env.setProperty(Context.SECURITY_PRINCIPAL, "guest");
                               env.setProperty(Context.SECURITY_CREDENTIALS, "guest123");
                               env.setProperty(Context.PROVIDER_URL, "jnp://localhost:1099");
                               env.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
                               env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.JndiLoginInitialContextFactory");
                   InitialContext ctx = new InitialContext(env);
                   TestTransRemote ttr = (TestTransRemote)ctx.lookup("TestTransImpl/remote");
                   ttr.testTransactions();
              }catch(Exception e){
                   e.printStackTrace();
                   throw e;
    }Remote Interface for TestTransImpl Stateless Session Bean
    public interface TestTransRemote extends Serializable {
         public void testTransactions() throws Exception;
    }TestTransImpl Stateless Session Bean
    @Stateless
    @Remote(TestTransRemote.class)
    public class TestTransImpl implements TestTransRemote {
         private static final long serialVersionUID = 1L;
         @TransactionAttribute(TransactionAttributeType.REQUIRED)
         public void testTransactions() throws Exception{
              java.sql.Connection conn = getConnection();
              java.sql.PreparedStatement ps;
              ps = conn.prepareCall("insert into cust(loc,cust_no) values ('001',20)");
              ps.execute();
              System.out.println("OUTSIDE FUNCTION - Customer 20 created");
              requiredNewFunction();
              ps = conn.prepareCall("Select cust_no from cust where loc = '001' and cust_no = 24");
              java.sql.ResultSet results = ps.executeQuery();
              results.next();     
              System.out.println("OUTSIDE FUNCTION - Customer Read - Cust No = " + results.getLong("cust_no"));
              throw new RuntimeException();
         @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
         private void requiredNewFunction() throws Exception{
              java.sql.Connection conn = getConnection();
              java.sql.PreparedStatement ps;
              ps = conn.prepareCall("Select cust_no from cust where loc = '001' and cust_no = 20");
              java.sql.ResultSet results = ps.executeQuery();
              results.next();     
              System.out.println("INSIDE FUNCTION - Customer Read - Cust No = " + results.getLong("cust_no"));
              ps = conn.prepareCall("insert into cust(loc,cust_no) values ('001',24)");
              ps.execute();
              System.out.println("INSIDE FUNCTION - Customer 24 created");
         private java.sql.Connection getConnection() throws Exception{
              javax.sql.DataSource ds;
              javax.naming.InitialContext ic = new javax.naming.InitialContext();
              ds = (javax.sql.DataSource)ic.lookup("java:MyOracleDS");
              java.sql.Connection conn = ds.getConnection();
              return conn;          
    }Datasource XML File
    <?xml version="1.0" encoding="UTF-8"?>
    <datasources>
        <local-tx-datasource>
            <jndi-name>MyOracleDS</jndi-name>
            <connection-url>jdbc:oracle:thin:XXXXX(DB Host):1521:XXXXX(DB Sid)</connection-url>
            <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
            <user-name>XXXXX(username)</user-name>
            <password>XXXXX(password)</password>
            <min-pool-size>5</min-pool-size>
            <max-pool-size>100</max-pool-size>
            <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
            <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
            <metadata>
                <type-mapping>Oracle10g</type-mapping>
            </metadata>
        </local-tx-datasource>
    </datasources>Program Output
    08:43:41,093 INFO  [STDOUT] OUTSIDE FUNCTION - Customer 20 created
    08:43:41,125 INFO  [STDOUT] INSIDE FUNCTION - Customer Read - Cust No = 20
    08:43:41,140 INFO  [STDOUT] INSIDE FUNCTION - Customer 24 created
    08:43:41,140 INFO  [STDOUT] OUTSIDE FUNCTION - Customer Read - Cust No = 24

    All ejb invocation behavior, including authorization, container-managed transactions, etc. only applies when the call is made through one of the appropriate ejb client objects. If
    TestTransImpl.testTransactions() directly invokes requiredNewFunction() it's just a normal java
    method call -- the ejb container has no idea it's happening and is not interposing. If you want
    the full ejb invocation behavior when you invoke requiredNewFunction() you'll need to
    make sure requiredNewFunction is part of a business interface, is public, and is invoked through
    the corresponding ejb reference :
    @Resource private SessionContext ctx;
    public void testTransactions() throws Exception {
    TestTransRemote testTrans = ctx.getBusinessObject(TestTransRemote.class);
    testTrans.requiredNewFunction();
    }

  • Database transaction management in Web services

    Hi,
    I am using Oracle8i and firing some database queries from my web services. I want to do the transaction management for the same i.e. When one of the queries fail, i want to rollback. But when i write my own transaction management, it gives me an error :
    java.sql.SQLException: Cannot call Connection.commit in distributed transaction.Transaction Manager will commit the resource manager when the distributed transaction is committed.
    Can anyone please help me out as to how to perform the database transaction management in web services.
    Thanking in advance.
    Prashant

    Unfortunately to manage transactions over web services there is no viable solution available in market. All implementations come with restrictions e.g. Metro works with only EJBs on Glassfish, JBossTS works on JBoss but not with JAX-WS, Atomikos supports only Axis as of now.
    1. See explanation above.
    2. Yes, it can be but conditions mentioned above are applied :-)
    3. [www.oasis-open.org/committees/ws-tx/|www.oasis-open.org/committees/ws-tx/]
    4. Unfortunately as of now I do not see an easy way to this problem.

  • Java user-defined transaction management not working correctly???

    Hi everyone,
    I have encountered a problem when using Java user-defined transaction management in my session bean. It threw an exception but I could not work out what that means. Could anyone comment on this? Thanks.
    This BrokerBean is a stateless session calling other entities bean to perform some simple operations. There are 2 Cloudscape databases in use. Invoices (EB) use InvoiceDB and all the other EBs use StockDB.
    If I comment out the user-defined transaction management code, then everything works fine. Or if I comment out the Invoices EB code, it is fine as well. It seemed to me that there is something wrong in transaction management when dealing with distributed databases.
    --------------- source code ----------------------
    public void CreateInvoices(int sub_accno) {
    try {
    utx = context.getUserTransaction();
    utx.begin();
    SubAcc subAcc = subAccHome.findByPrimaryKey(new SubAccPK(sub_accno));
    String sub_name = subAcc.getSubName();
    String sub_address = subAcc.getSubAddress();
    Collection c = stockTransHome.findBySubAccno(sub_accno);
    Iterator i = c.iterator();
    ArrayList a = new ArrayList();
    while (i.hasNext()) {
    StockTrans stockTrans = (StockTrans)i.next();
    int trans_id = stockTrans.getTransID();
    String tran_type = stockTrans.getTranType();
    int stock_id = stockTrans.getStockID();
    float price = stockTrans.getPrice();
    Invoices invoices = invoicesHome.create(sub_accno, sub_name, sub_address, trans_id, stock_id, tran_type, price);
    stockTrans = stockTransHome.findByPrimaryKey(new StockTransPK(trans_id));
    stockTrans.remove();
    utx.commit();
    utx = null;
    } catch (Exception e) {
    if (utx != null) {
    try {
    utx.rollback();
    utx = null;
    catch (Exception ex) {}
    // e.printStackTrace();
    throw new EJBException("BrokerBean.CreateInvoices(): " + e.getMessage());
    --------------- exception ----------------------
    Initiating login ...
    Enter Username:
    Enter Password:
    Binding name:`java:comp/env/ejb/BrokerSB`
    EJB test succeed
    Test BuyStock!
    Test BuyStock!
    Test BuyStock!
    Test BuyStock!
    Test SellStock!
    Test SellStock!
    Caught an exception.
    java.rmi.ServerException: RemoteException occurred in server thread; nested exce
    ption is:
    java.rmi.RemoteException: BrokerBean.CreateInvoices(): CORBA TRANSACTION
    _ROLLEDBACK 9998 Maybe; nested exception is:
    org.omg.CORBA.TRANSACTION_ROLLEDBACK: vmcid: 0x2000 minor code: 1806
    completed: Maybe
    at com.sun.corba.ee.internal.iiop.ShutdownUtilDelegate.mapSystemExceptio
    n(ShutdownUtilDelegate.java:64)
    at javax.rmi.CORBA.Util.mapSystemException(Util.java:65)
    at BrokerStub.CreateInvoices(Unknown Source)
    at Client.main(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
    java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
    sorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at com.sun.enterprise.util.Utility.invokeApplicationMain(Utility.java:22
    9)
    at com.sun.enterprise.appclient.Main.main(Main.java:155)
    Caused by: java.rmi.RemoteException: BrokerBean.CreateInvoices(): CORBA TRANSACT
    ION_ROLLEDBACK 9998 Maybe; nested exception is:
    org.omg.CORBA.TRANSACTION_ROLLEDBACK: vmcid: 0x2000 minor code: 1806
    completed: Maybe
    at com.sun.enterprise.iiop.POAProtocolMgr.mapException(POAProtocolMgr.ja
    va:389)
    at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:43
    1)
    at BrokerBean_EJBObjectImpl.CreateInvoices(BrokerBean_EJBObjectImpl.java
    :265)
    at BrokerBeanEJBObjectImpl_Tie._invoke(Unknown Source)
    at com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatchToServant(Ge
    nericPOAServerSC.java:520)
    at com.sun.corba.ee.internal.POA.GenericPOAServerSC.internalDispatch(Gen
    ericPOAServerSC.java:210)
    at com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatch(GenericPOAS
    erverSC.java:112)
    at com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:255)
    at com.sun.corba.ee.internal.iiop.RequestProcessor.process(RequestProces
    sor.java:84)
    at com.sun.corba.ee.internal.orbutil.ThreadPool$PooledThread.run(ThreadP
    ool.java:99)

    Three things:
    first, maybe you should think of putting ut.begin() just before the invoicesHome.create() method and ut.commit() just after the stockTrans.remove() method.It wont solve the current problem but will help in performance once the problem is solved.
    second, your utx.commit() is outside the try block. how come the code is compiling then??
    third, try doing a SOP call before and after invoicesHome.create() method and see where the problem actually lies.
    let us know...
    Hi SteveW2,
    Thanks for being so helpful. Here are my replies:
    Can I just ask why you're not using containermanaged
    transactions?The reason why I didn't use container managed
    transactions is because I don't really know how to do
    that. I am more familiar with this user-defined
    transaction handling.
    I have attempted to implement the same method in an
    entity bean and just let the container manage the
    rollback itself. The same exception was thrown when
    running the client.
    Also, the transaction behaviour is likely to relateto
    the app server youre using - which is it?What do you mean by the app server? I am using J2EE
    1.3.1 if that is what you meant.
    Finally, if your code has a problem rolling back,and
    throws an exception, you discard your exception
    thereby losing useful information.I have tried to print the exception stack as well, but
    it is the same as just printing the general
    exception.
    This problem is very strange cause if I comment out
    the transaction management thing, then everything
    works fine. Or if I am only working with 1 single
    database, with this user-defined transaction handling,
    everything works fine as well.
    Here is the error log from J2EE server if you are
    interested.
    ------------ error log ---------------
    javax.ejb.TransactionRolledbackLocalException:
    Exception thrown from bean; nested exception is:
    javax.ejb.EJBException: ejbCreate: Connection
    previously closed, open another Connection
    javax.ejb.EJBException: ejbCreate: Connection
    previously closed, open another Connection
         at InvoicesBean.ejbCreate(Unknown Source)
    at
    InvoicesBean_RemoteHomeImpl.create(InvoicesBean_Remote
    omeImpl.java:31)
         at InvoicesHomeStub.create(Unknown Source)
         at BrokerBean.CreateInvoices(Unknown Source)
    at
    BrokerBean_EJBObjectImpl.CreateInvoices(BrokerBean_EJB
    bjectImpl.java:261)
    at BrokerBeanEJBObjectImpl_Tie._invoke(Unknown
    Source)
    at
    com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispa
    chToServant(GenericPOAServerSC.java:520)
    at
    com.sun.corba.ee.internal.POA.GenericPOAServerSC.inter
    alDispatch(GenericPOAServerSC.java:210)
    at
    com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispa
    ch(GenericPOAServerSC.java:112)
    at
    com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:25
    at
    com.sun.corba.ee.internal.iiop.RequestProcessor.proces
    (RequestProcessor.java:84)
    at
    com.sun.corba.ee.internal.orbutil.ThreadPool$PooledThr
    ad.run(ThreadPool.java:99)
    javax.ejb.TransactionRolledbackLocalException:
    Exception thrown from bean; nested exception is:
    javax.ejb.EJBException: ejbCreate: Connection
    previously closed, open another Connection
    at
    com.sun.ejb.containers.BaseContainer.checkExceptionCli
    ntTx(BaseContainer.java:1434)
    at
    com.sun.ejb.containers.BaseContainer.postInvokeTx(Base
    ontainer.java:1294)
    at
    com.sun.ejb.containers.BaseContainer.postInvoke(BaseCo
    tainer.java:403)
    at
    InvoicesBean_RemoteHomeImpl.create(InvoicesBean_Remote
    omeImpl.java:37)
         at InvoicesHomeStub.create(Unknown Source)
         at BrokerBean.CreateInvoices(Unknown Source)
    at
    BrokerBean_EJBObjectImpl.CreateInvoices(BrokerBean_EJB
    bjectImpl.java:261)
    at BrokerBeanEJBObjectImpl_Tie._invoke(Unknown
    Source)
    at
    com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispa
    chToServant(GenericPOAServerSC.java:520)
    at
    com.sun.corba.ee.internal.POA.GenericPOAServerSC.inter
    alDispatch(GenericPOAServerSC.java:210)
    at
    com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispa
    ch(GenericPOAServerSC.java:112)
    at
    com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:25
    at
    com.sun.corba.ee.internal.iiop.RequestProcessor.proces
    (RequestProcessor.java:84)
    at
    com.sun.corba.ee.internal.orbutil.ThreadPool$PooledThr
    ad.run(ThreadPool.java:99)
    What is "connection previously closed, open another
    connection"? This might be the cause of the
    exception.
    I'll keep trying till I solve the problem.
    Thanks,
    Sasuke

  • Does transaction manager also releases the connections ?

    Hi All,
    I've a doubt regarding release of connection in transaction handling scenarios in EJB.
    Let us assume I have an EJB method associated with a transaction attribute as Requires New (i.e. the ejb method is associated with container managed transaction).
    Within that method two diffreent databasess are accessed, connections are created, databases are updated but connections are not realeased.
    The code goes similar to the one given below -
    public void beanMethod1()
    InitialContext cntx = new InitialContext();
    javax.sql.DataSource ds1 = cntx.lookup("dataSourceName1");
    javax.sql.DataSource ds2 = cntx.lookup("dataSourceName2");
    java.sql.Connection conn1 = ds1.getConnection();
    ds1.setAutoCommit(false);
    PreparedStatement pst1 = ds1.prepareStatement("Qyery1");
    pst1.executeUpdate();
    java.sql.Connection conn2 = ds2.getConnection();
    ds2.setAutoCommit(false);
    PreparedStatement pst2 = ds2.prepareStatement("Qyery2");
    pst2.executeUpdate();
    Now in this context my doubt is - will the transaction manager, along with handling commit/rollback, release the connections also (once commit/rollback is over) ? Or releasing of connections need to be handled in the bean method ?
    If releasing connections has to be handled in the bean method, then how does transaction manager execute a commit/rollback on a released connection ?
    The same doubt can be extended to bean managed transaction also where transaction boundarry is demarcated using javax.transaction.UserTransaction object's begin(), commit() and rollback() methods.
    It will be a real help if anyone please throw some light on this doubt.
    Thanks in advance,
    Sourav

    Hi,
    Your code needs to release (i.e., close) the connections it uses; this is outside the TM responsibility scope.
    The commit or rollback is not a problem, because the corresponding XAResource (which is the
    transaction manager's handle to your connection) can be used even after your connection
    has been closed in the application code. That is the catch about XA, and it allows the whole
    mechanism of connection pooling and DataSources to work properly.
    Hope that helps,
    Guy

  • Transaction Management using JDBC service

    In Adobe Livecycle 8.2 JDBC service do not provide exception handling.
    How to start trasaction from client Java application running on another machine and pass it to customised process having JDBC service
    Should transaction be started on client machine using JNDI lookup of Transaction manager of Livecycle application server
    How to rollback transaction when Java application get error from EJB end point.

    Hello Amit!
    It is true that LiveCycle 8.2's JDBC service has on built-in exception handling.  This has been remedied in 9.0 as there are now several exception types that can be handled.
    If I understand correctly, your trouble comes with the lack of transaction management around the existing JDBC service within LiveCycle.  To this I can only recommend that any SQL statements needing to be run with transaction management be done so within an executeScript service.  I have, on many, many occasions, utilized this service to write some custom code using the Statement and/or PreparedStatement classes to handle any database interactions.
    In addition to the above, it seems as though you would like to leverage the JNDI lookup capability of LiveCycle's JDBC service so you can specify a data source name as opposed to having to establish your own connection.  This too can be handled within the executeScript service via custom code.  As an example, the following code, when dropped in an executeScript service, will establish a connection to an Oracle database via JNDI lookup:
    import oracle.sql.*;
    import java.sql.Connection;
    import java.sql.PreparedStatement;
    import javax.naming.InitialContext;
    import org.jboss.resource.adapter.jdbc.WrappedConnection;
    import oracle.jdbc.OracleConnection;
    InitialContext ctx = new InitialContext();
    String sDataSource = "YOUR DATA SOURCE NAME HERE";
    Connection conn = ((DataSource)ctx.lookup(sDataSource)).getConnection();
    org.jboss.resource.adapter.jdbc.WrappedConnection oWConn = (WrappedConnection) conn;
    OracleConnection oConn = oWConn.getUnderlyingConnection();
    From that point forward, you can simply leverage the PreparedStatement and/or Statement classes for any statements.
    Please do let me know if you have any questions.
    Josh Boyle
    [email protected]
    Cardinal Solutions Group

  • Transaction Management - OIM API

    We wanted to know how to handle transaction from OIMClient, when we make OIM API call.
    eg:
    from a java client, we invoke create organization and provision resource to that organization.
    i.e we end up calling two OIM api calls
    1)
        organizationManager.create(organizationObj);
    2)
    tcOrganizationOperationsIntf.provisionObject(orgKey,resourceKey);
    Now, if 2nd one fails, then transaction should be rolled back and organization create should be rolled back. we wanted single unit of work to be achieved.
    how can this be achieved?
    how do we control transaction from OIMClient/API?
    public String createOrganization(OrganizationVO ovo) {
      String result = "";
      OrganizationManager omgr = null; // OIMClient API
      Organization org = null; // OIMClient API
      try { 
      omgr=ULMServiceLocator.getInstance().getOrganizationManager();
      org = new Organization();
      org.setAttribute("Organization Name", ovo.getOrgName());
      org.setAttribute("Organization Customer Type", ovo.getOrgType());
      result = omgr.create(org);
      tcUtilityFactory ioutilityFactory = ULMServiceLocator.getInstance().getcUtilityFactory();
      //TODO
      tcOrganizationOperationsIntf utilityFactory1 = (tcOrganizationOperationsIntf) ioutilityFactory
      .getUtility("Thor.API.Operations.tcOrganizationOperationsIntf");
      long l1 = utilityFactory1.provisionObject(Long.parseLong(result),
      123l);
      } catch (oracle.jrf.UnknownPlatformException e) {
      e.printStackTrace();
      } catch (Exception e) {
      // TODO Auto-generated catch block
      e.printStackTrace();
      return result;

    Hi Abhay,
    <b>If there is another way to add a record to Main table and Lookup/Qualified/Hierarchy table simultaneously then there is no need of Transaction.</b>
    There are no direct methods currently(as of MDM 5.5SP3) available in MDM API.
    You have to build your own logic to implement.
    Regarding the Transaction management, I guess you are talking aboout two phase commit scenarios. I would say you can achieve this using EJB's in which u write the business logic (In this case the MDM API code).
    For Example:
    Adding a record to Main table,
    Let say 2 fields
    1. Free text field.
    Its straight forward method, use A2iFiled object and assign some value to it.
    2. Lookup field.
    For this.
    First get the Record id for the value, which you are trying to add, from the lookup table.
    If the lookup table does not find the value in the table, it return zero or some negative value(which I am not sure).
    Based on the return value you can add the value into the lookup table and then into the main table.
    Just putting a sample scenario. Hope this helps.
    Thanks and regards
    Subbu

  • BPEL Transaction Management from Client Caller

    Hi Guys,
    I have read many articles and postings so far on transaction management, but they all seem to relate to within the BPEL process itself. I want to know if the following is doable within BPEL and if so how to configure it.
    - I have a J2EE application that integrates with BPEL through the ITaskService (using Remote EJBs underneath the cover) - Oracle BPEL is installed on a separate machine on the OC4J container.
    - So, is there a way for the operations done to the ITaskService to participate in my J2EE application's transaction, to give you an example:
    - Begin Transaction()
    - user does something that results in updating a task's attribute
    - some other operations are being performed; if there is an exception thrown, roll back
    - End Transaction()
    Thanks very much in advance.
    Drew

    Hi Drew,
    Please refer Antony Reynold's blog:
    http://blogs.oracle.com/reynolds/2008/09/transaction_processing_in_bpel.html
    It says when the BPEL Process is invoked from a java API that has its own
    transaction context, the BPEL Process also will participate in the same
    transaction context.
    Hope this helps.
    Thanks,
    Vasanth

  • Forte Transaction Management & 2PC

    Forte Transaction Management & 2PC
    The main purpose of 2PC in a distributed transaction manager is
    to enable recovery from a failure that occurs during the window
    of transaction commit processing. The Forte transaction manager was built
    with this in mind but only with respect to the "volatile" (or "in memory")
    objects that Forte manages. What this implies is that because Forte stores
    objects in memory and not persistently on disk, the requirement of recovery
    for these objects is significantly reduced (if not eliminated all together).
    Forte follows a distributed 2PC model in that tasks and messages carry
    along with them transaction identification and, during commit processing,
    every distributed participant is polled for its availability to commit
    the transaction. Applications saving persistent data to disk during a
    distributed Forte transaction need to concern themselves with the potential
    for failure during the commit processing window. Forte's prepare phase polls
    each site (confirming a communications link with each distributed participant)
    but no prepare request goes to the database primarily because (in release 1 and
    2 of forte) no database supported a general distributed two-phase commit
    (one could take issue with that in the case of Sybase, but rather than debate
    this point, suffice it to say that the general direction in the industry for
    support of this functionality was through TP monitors -- more on that later).
    Once all sites are ready to commit Forte expects that the commit will
    complete successfully. If at this moment, for example, a participating
    Sybase server terminates (with data not yet committed) while a participating
    Oracle server has already committed its unit of work, then the outcome of
    the distributed transaction is inconsistent - if no one has yet committed
    Forte will still abort the transaction. This "window of inconsistency"
    is documented in the Forte TOOL manual.
    Mission critical applications that require distributed transactions can
    address this window of inconsistency in a number of ways:
    * Utilize a TP monitor such as Encina (see below)
    * Log distributed updates in an auxiliary database table (much like a
    distributed transaction monitor's transaction-state log). This approach has
    been the traditional banking application solution prior to the commercial
    availability of products like Encina, Tuxedo, TopEnd, etc.
    This solution is somewhat complex and is usually not generic enough
    so as not to have to change code every time a new table or database
    site is introduced into the application's data model.
    * Rearrange the data model in order to eliminate the need for distributed
    transactions. This is usually only a temporary solution (with smaller
    numbers of active clients) and cannot be applied to complex legacy systems.
    With the advent of the X/Open distributed transaction architecture (the
    XA Interface) more database vendors have found that by complying with the
    XA interface they can plug their database-specific implementation of
    transaction into a globally managed transaction, with commit and abort
    processing being conducted by a central coordinator. Of course, the
    overall transaction manager coordinating the global transaction must
    itself, persistently record the state of the different distributed
    branches participating in the transaction. A significant portion of
    the functionality provided by products such as Encina, Tuxedo, TopEnd and
    OpenTP1 is to provide exactly this global transaction management.
    Rather than extend the Forte distributed transaction manager with the
    functionality necessary to manage and recover distributed transactions
    that modify data on disk, Forte has chosen to integrate with the emerging
    set of commercial transaction monitors and managers. This decision was
    built into the original design of the Forte transaction model (using XA and
    early Tuxedo white-papers as guidelines):
    * In Forte release 2 an integration with Encina was delivered.
    * In January 1997 a press release announced an integration of
    OpenTP1 with Forte for release 3.
    * The Forte engineering staff is currently investing integration
    with other transaction management products as well.
    Neil Goodman,
    Forte Development.

    You don't. ("manage" a transaction)
    There is nothing really to "manage".
    A transaction is automatically started when you make any changes to data (e.g. fire off a DML statement).
    You simply needs to issue a COMMIT or ROLLBACK when needed. A COMMIT at the end of the business transaction and not before (i.e. no committing every n number of rows). A ROLLBACK when hitting an exception or business logic error that requires the uncommitted changes to be undone.
    That in a nutshell is it. It is that simple.
    Oracle also supports creating savepoints and rolling back only some changes made thus far in the transaction.
    The only other thing to keep in mind that a DDL in Oracle issues an implicit commit. Firing off a DDL with cause any exiting uncommitted transaction to be committed.
    Transaction "logic/management" should not be made more complex than this.

  • Error while Running Receiving Transaction Manager

    Hi.,
    We have 11..5.10.2 on AIX 5.3 intermeditley we are getting the below error for Receiving Transaction Manager. for temporary sloution we will restart the Receiving Transaction Manager is there any permanent solution for this.....?
    we have two Receiving Transaction Manager process.
    Error
    "APP 00204: Concurrent manager encountered an error while running the spawned
    concurrent program Receiving Transaction Manager: rcvoltm TM:Timeout"

    Hello.
    Have a look on MOS Doc ID 1071727.1
    Octavio

  • Receiving Transaction Manager Time out in iProcurement Receiving!

    Hi All,
    Database:10.2.0.4.0
    Oracle Aps:12.0.6
    O/S:AIX 64 bits 5.3 L
    We are unable to create any receipts due to following error.Checked Receiving Transaction Manager and that is running fine.
    Error Message
    Your receipt could not be created successfully because your receiving transaction manager timed out.
    Please contact your System Administrator for further assistance.
    Steps To Reproduce
    The issue can be reproduced at will with the following steps:
    1. In Iprocurement select requisition to receive
    2. Enter required data and press submit
    3. on screen receive Items: review and submit get above error message
    Profile RCV: Processing Mode is currently set to 'online'
    Could anyone please share resolution to such an issue faced before.
    Thanks for your time!
    Regards,

    Follow the Metalink ID: 375152.1

Maybe you are looking for