Rollback a transaction in a session bean BMP?

The following code would work correctly if executed in a stateless session bean BMP?
InitialContext ic = new InitialContext();
javax.sql.DataSource dataSource = (javax.sql.DataSource) ic.lookup("java:comp/env/jdbc/OracleDS");
Connection conn = dataSource.getConnection();     
conn.setAutoCommit(false);
Statement stmt = conn.createStatement("UPDATE TABLE_A SET NAME = 'Duke' WHERE ID = 7");
stmt.executeUpdate();
if (someCondition) {
conn.commit();
} else {
conn.rollback();
My question:
It�s possible to rollback a transaction using rollback() from Connection class in a stateless
session bean BMP?

Dear JDC member:
With EJB, you can gain the benefit of transactions without performing any transaction programming. That is, your enterprise beans never explicitly issue a begin, commit, or abort statement. The container performs it to you. But you have to tell the container how to do it. As you might know, the deploment descriptor is the place for it.
But nothing prevent you to do do programmatic transaction as you want.. For that case you have to know JTA (Java Transaction API) and more.
Suppose the transaction aborts, you have to throw an exception back to the client or try it again. The issue here is with stateless sesssion beans, there is no in-memory conversational state. You might think to implement javax.ejb.SessionSynchronization interface with your business methods....
You see there is a lot to know. You can take care of transactions in the client code, but it is a bad design.
You have to understand today most application servers (Websphere, Weblogic...) are designed to minimize those issues in order to make developers' tasks easier. The container takes care of transactions.
Be careful when you write stateless session beans BMP (BMP are for entiti beans)
Regards,
Armand Komenan

Similar Messages

  • Handling Transaction in Stateful Session Bean

    I wrote a public method like public void doTransaction()
    it will call 2 private method, like: methodA and methodB
    Both private methods have db accesss statement and will update the db. They got different db connection and will close the connection when method call finished.
    How to include them to one transaction? I want to be able to rollback the job of the first method when I catch exception thrown by the second method.
    I tried simply define transaction type of the public method to be Container and Required. But it doesn't work, the first method doesn't rollback. Of course I can let the 2 private methods share a same connection and commit after finishing calling them. But how if they are in different DB?

    Ok... Here it goes...
    You can do it in the following manner.
    As you said you have got 2 private methods doing d/b updates and these are called from a public method.
    Stateful session beans since associated with a client across methods, you can take advantage of it. Write your own user defined transaction.
    Begin the transaction scope in your public before calling the 1st private method. Call the 2 methods in a try block. Once you are done with these methods, you can commit and end the transaction. If you get any exception, rollback the transaction in the catch block. Otherwise if u get any exception in the 2nd method, you can rollback the transaction there itself.
    Stateful session beans lets u allow to spawn the bean managed transaction across methods. you can begin your transaction in one method and end it in a differnt method or you can end the transaction after calling the methods.
    The problem you are dealing with can typically very well handled by writing bean managed transaction.
    Hope this helps. If you need anymore clarity on my solution, please let me know.
    -amit

  • Transaction using stateful session bean.

    All,
    I was implementing "Transaction" part using statefull session(trying to understand how transaction work).
    I created a Statefull session bean, here in one method create 2 sql queries
    query1:update Employees set LastName='newname' where EmployeeID = 9
    query2:update Customers set CompanyName = 'newname Inc.' ContactName = 'Maria Anders'
    "query1" works fine, but "query2" is not correct(syntax error) hence will not be executed. This will throw a SQLException.
    According to EJBspec, rollback will happen if there is a system exception. And I guess SQLException is systemexception.
    But when I query "Employees" table, I get the data updated through the "query1".
    What I was excepting was the first query which was executed should have rolled back because the second query has thrown a SQLException.
    I tried using ContainerManaged transaction and BeanManaged transaction.
    But in both cases transaction is not getting rolled back.
    I have tried with REQUIRED and REQUIRESNEW attributes for container managed transactions with Isolation level as Read Commited.
    Is my understanding correct?
    TIA,
    Vijay

    Tried using Bean managed transactions but with the same result. Given below is the sample code.
    UserTransaction uts = null;
    try {
    uts = (UserTransaction)(ctx.getUserTransaction());
    uts.begin();
    Connection con = null;
    con = getCountConnection();
    PreparedStatement ps = con.prepareStatement(sqlselectUserId);
    ps.executeUpdate();
    PreparedStatement ps1 = con.prepareStatement(sqlselectUserDetails);
    ps1.executeUpdate();
    uts.commit();
    catch(SQLException e) {
         uts.rollback();

  • Rolling back the transaction from stateful session bean

    Hi,
    How can I mark the transaction to be rolled back in a stateful session bean implementation?.
    Should I call setRollbackOnly method or throw a RemoteException or throw an EJBException, etc.?
    the configuration is :
    OC4J 9.0.4
    Stateful session bean
    Related method has transaction attribute - "Required"
    thanks & regards.
    ps : I couldn't find a related topic even if this has been discussed before (too many topics). if so, excuses.
    Erdem.

    Tried using Bean managed transactions but with the same result. Given below is the sample code.
    UserTransaction uts = null;
    try {
    uts = (UserTransaction)(ctx.getUserTransaction());
    uts.begin();
    Connection con = null;
    con = getCountConnection();
    PreparedStatement ps = con.prepareStatement(sqlselectUserId);
    ps.executeUpdate();
    PreparedStatement ps1 = con.prepareStatement(sqlselectUserDetails);
    ps1.executeUpdate();
    uts.commit();
    catch(SQLException e) {
         uts.rollback();

  • NON-transactional session bean access entity bean

    We are currently profiling our product using Borland OptmizeIt tool, and we
    found some interesting issues. Due to our design, we have many session beans which
    are non transactional, and these session beans will access entity beans to do
    the reading operations, such as getWeight, getRate, since it's read only, there
    is no need to do transaction commit stuff which really takes time, this could
    be seen through the profile. I know weblogic support readonly entity bean, but
    it seems that it only has benefit on ejbLoad call, my test program shows that
    weblogic still creates local transaction even I specified it as transaction not
    supported, and Transaction.commit() will always be called in postInvoke(), from
    the profile, we got that for a single method call, such as getRate(), 80% time
    spent on postInvoke(), any suggestion on this? BTW, most of our entity beans are
    using Exclusive lock, that's the reason that we use non-transactional session
    bean to avoid dead lock problem.
    Thanks

    Slava,
    Thanks for the link, actually I read it before, and following is what I extracted
    it from the doc:
    <weblogic-doc>
    Do not set db-is-shared to "false" if you set the entity bean's concurrency
    strategy to the "Database" option. If you do, WebLogic Server will ignore the
    db-is-shared setting.
    </weblogic-doc>
    Thanks
    "Slava Imeshev" <[email protected]> wrote:
    Hi Jinsong,
    You may want to read this to get more detailed explanation
    on db-is-shared (cache-between-transactions for 7.0):
    http://e-docs.bea.com/wls/docs61/ejb/EJB_environment.html#1127563
    Let me know if you have any questions.
    Regards,
    Slava Imeshev
    "Jinsong HU" <[email protected]> wrote in message
    news:[email protected]...
    Thanks.
    But it's still not clear to me in db-is-shared setting, if I specifiedentity
    lock as database lock, I assumed db-is-shared is useless, because foreach
    new
    transaction, entity bean will reload data anyway. Correct me if I amwrong.
    Jinsong
    "Slava Imeshev" <[email protected]> wrote:
    Jinsong,
    See my answers inline.
    "Jinsong Hu" <[email protected]> wrote in message
    news:[email protected]...
    Hi Slava,
    Thanks for your reply, actually, I agree with you, we need to
    review
    our db
    schema and seperate business logic to avoid db lock. I can not say,guys,
    we need
    to change this and that, since it's a big application and developedsince
    EJB1.0
    spec, I think they are afraid to do such a big change.Total rewrite is the worst thing that can happen to an app. The
    better aproach would be identifying the most critical piece and
    make a surgery on it.
    Following are questions in my mind:
    (1) I think there should be many companies using weblogic serverto
    develop
    large enterprise applications, I am just wondering what's the maintransaction/lock
    mechanism that is used? Transional session / database lock,
    db-is-shared
    entity
    I can't say for the whole community, as for my experience the standard
    usage patthern is session fasades calling Entity EJBs while having
    Required TX attribute plus plain transacted JDBC calls for bulk
    reads or inserts.
    is the dominant one? It seems that if you speficy database lock,
    the
    db-is-shared
    should be true, right?Basically it's not true. One will need db-is-shared only if thereare
    changes
    to the database done from outside of the app server.
    (2) For RO bean, if I specify read-idle-timeout to 0, it shouldonly
    load
    once at the first use time, right?I assume read-timeout-seconds was meant. That's right, but if
    an application constantly reads new RO data, RO beans will be
    constantly dropped from cache and new ones will be loaded.
    You may want to looks at server console to see if there's a lot
    of passivation for RO beans.
    (3) For clustering part, have anyone use it in real enterpriseapplication?
    My concern, since database lock is the only way to choose, how aboutthe
    affect
    of ejbLoad to performance, since most transactions are short live,if high
    volume
    transactions are in processing, I am just scared to death about
    the
    ejbLoad overhead.
    ejbLoad is a part of bean's lifecycle, how would you be scared ofit?
    If ejbLoads take too much time, it could be a good idea to profile
    used SQLs. Right index optimization can make huge difference.
    Also you may want cosider using CMP beans to let weblogic
    take care about load optimization.
    (4) If using Optimization lock, all the ejbStore need to do
    version
    check
    or timestamp check, right? How about this overhead?As for optimistic concurrency, it performs quite well as you can
    use lighter isolation levels.
    HTH,
    Slava Imeshev
    "Jinsong Hu" <[email protected]> wrote in message
    news:[email protected]...
    We are using Exclusive Lock for entity bean, because of we do
    not
    want
    to
    load
    data in each new transaction. If we use Database lock, that means
    we
    dedicate
    data access calls to database, if database deadlock happens,
    it's
    hard
    to
    detect,
    while using Exclusive lock, we could detect this dead lock in
    container
    level.
    The problem is, using Exclusive concurrency mode you serialize
    access to data represented by the bean. This aproach has negative
    effect on ablity of application to process concurrent requests.As
    a
    result the app may have performance problems under load.
    Actually, at the beginnning, we did use database lock and usingtransactional
    The fact that you had database deadlocking issues tells that
    application logic / database schema may need some review.
    Normally to avoid deadlocking it's good to group database
    operations mixing in updattes and inserts into one place so
    that db locking sequence is not spreaded in time. Moving to
    forced serialized data access just hides design/implementation
    problems.
    session bean, but the database dead lock and frequent ejbLoad
    really
    kill
    us,
    so we decided to move to use Exclusive lock and to avoid dead
    lock,
    we
    change
    some session bean to non-transactional.Making session beans non-transactions makes container
    creating short-living transactions for each call to entity bean
    methods. It's a costly process and it puts additional load to
    both container and database.
    We could use ReadOnly lock for some entity beans, but since weblogicserver will
    always create local transaction for entity bean, and we found
    transaction
    commit
    is expensive, I am arguing why do we need create container leveltransaction for
    read only bean.First, read-only beans still need to load data. Also, you may seeRO
    beans
    contanly loading data if db-is-shared set to true. Other reason
    can
    be
    that
    RO semantics is not applicable the data presented by RO bean (forinstance,
    you have a reporting engine that constantly produces "RO" data,
    while
    application-consumer of that data retrieves only new data and neverasks
    for "old" data). RO beans are good when there is a relatively stable
    data
    accessed repeatedly for read only access.
    You may want to tell us more about your app, we may be of help.
    Regards,
    Slava Imeshev
    I will post the performance data, let's see how costful
    transaction.commit
    is.
    "Cameron Purdy" <[email protected]> wrote:
    We are currently profiling our product using Borland
    OptmizeIt
    tool,
    and we
    found some interesting issues. Due to our design, we have
    many
    session
    beans which
    are non transactional, and these session beans will access
    entity
    beans
    to
    do
    the reading operations, such as getWeight, getRate, since
    it's
    read
    only,
    there
    is no need to do transaction commit stuff which really takes
    time,
    this
    could
    be seen through the profile. I know weblogic support readonly
    entity
    bean,
    but
    it seems that it only has benefit on ejbLoad call, my test
    program
    shows
    that
    weblogic still creates local transaction even I specified
    it
    as
    transaction not
    supported, and Transaction.commit() will always be called
    in
    postInvoke(),
    from
    the profile, we got that for a single method call, such as
    getRate(),
    80%
    time
    spent on postInvoke(), any suggestion on this? BTW, most of
    our
    entity
    beans are
    using Exclusive lock, that's the reason that we use
    non-transactional
    session
    bean to avoid dead lock problem.I am worried that you have made some decisions based on an improper
    understand of what WebLogic is doing.
    First, you say "non transactional", but from your description
    you
    should
    have those marked as tx REQUIRED to avoid multiple transactions
    (since
    non-transactional just means that the database operation becomesits
    own
    little transaction).
    Second, you say you are using exclusive lock, which you shouldonly
    use
    if
    you are absolutely sure that you need it, (and note that it
    does
    not
    work in
    a cluster).
    Peace,
    Cameron Purdy
    Tangosol, Inc.
    http://www.tangosol.com/coherence.jsp
    Tangosol Coherence: Clustered Replicated Cache for Weblogic
    "Jinsong Hu" <[email protected]> wrote in message
    news:[email protected]...
    >

  • Transaction management in BMP through Session bean(worked in J2EE RI)

    This thing worked in the J2EE RI implementation, but not in OC4J.
    Problem is:
    In a BMP, if we throw an EJBException all the changes would be rolled back by the container, right? Or do we have to write code to do that?
    I was reading through your reply in the list and I have a doubt regarding something regarding transaction handling in BMP entity beans. I am using the entity bean in a session bean and have two sql statements and one entity update. If one of the sql statements fails and the entity is updated , the changes are all rolled back, but in the case of the entity failure to update, the sql statement changes are not rolled back and I get an error saying
    System/communication error: Transaction was rolled back: Error preparing bean in
    stance: com.evermind.transaction.MarshallingXAException; nested exception is:
    com.evermind.transaction.MarshallingXAException
    The entity bean is throwing an EJBException back to the Session bean, but the session bean does not catch
    it and continues forward as if nothing happened.
    The funny thing is that the queries are placed like this
    sqlinsert 1.......
    entitybean update....
    sqlinsert 2.....
    So the flow becomes
    sqlinsert 1 happens then sqlinsert 2 and only in the end does the entity bean throw the exception
    any idea why this happens?
    Can anyone help me on this. The BMP entity has persistence
    <persistence-type>Bean</persistence-type>
    Thanks
    Kind Regards
    Aby Philip

    Hi,
    In general, whenever you manage your own transactions (such as in DAOs or in stored procedures) then you are limiting the ways that your code can be reused: your code will never be able to run in a client's transaction. This could mean trouble if you want to combine you software inside other beans that use it: when these other beans lead to a rollback then your DAO might still commit.
    I would try to make the session bean use CMT, that is the most flexible if you are staying within the appserver.
    Hope that helps,
    Guy
    http://www.atomikos.com

  • Session Bean Transaction Rollback not working for RuntimeException

    Hi,
    I am calling a number of JDBC create/update statements within a method in a container managed transaction stateless session bean with transaction attribute set to required. I am running the bean within the embedded OC4J supplied with JDeveloper 10g (10.1.2). For each JDBC call, i connect to a datasource via JNDI containg a pool of connections pointing to an Oracle 10g database (standard J2EE)
    If i throw a runtime exception within the method the transaction is NOT rolled back as it should be according to the EJB spec. However, if i setRollbackOnly() on the session bean SessionContext the transaction does roll back.
    Has anybody experienced this before?
    Is this an OC4J bug?
    Thanks
    Dave

    Generally, for urgent issues it's best to open a SR with Oracle Support rather than posting to the forums.
    enlist=dynamic didnt exist in 10.2.0.2.20, but does now. I can't recall what specific version it was introduced though.
    enlist=false prevents enlistment in MSDTC transactions, so thats why it's not rolling back in that case.
    "transaction branch length 90 is illegal" was a known issue on Vista, is that the OS you're using? It takes a two part fix, and It is resolved by
    1) getting up to 10204 ODP (apply the 10204 rdbms patch to your client install)
    2) applying SP1 for Vista
    Hope it helps,
    Greg

  • 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

  • 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
              >>>
              >>
              >
              

  • 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.
              >
              >
              

  • Making AQ usage transactional across session beans, using mosly JMS syntax

    I need to determine what I need to have in place in order for JMS/AQ messages to be "fully transactional".
    I have a J2EE server application that will send JMS/AQ messages to a queue. I have a standalone application that reads messages from the queue, does some work, and then makes calls on multiple session beans (hosted in the original J2EE server application). Actually, it would likely be multiple calls to the same session bean method.
    Once the standalone application reads a message from the queue, I need to ensure that if any action performed as a result of that message fails, that all the operations performed, including the removal of the message from the queue, are rolled back.
    First of all, if I use an Oracle XA-compliant datasource, if one of the session bean calls fail, I can rollback the current transaction, but will this properly roll back any work that earlier session bean calls (made on the same transaction) did, even if they were successful (at the time)? Note that I have two JVMs, one running the J2EE application, and the other a standalone application reading from the queue.
    Second, on committing or rolling back the message retrieval itself, I noticed from examples in the Oracle AQ Application Developer's Guide that if I create my QueueSessions with "AQDriverManager.createAQSession()", that I can pass a Connection object, and then later "commit" or "rollback", manually, perhaps if I got an EJBException from a session bean call.
    However, I am trying to write my JMS/AQ code so that it uses as little of the direct AQ api as possible, staying with the standard JMS api. As a result, I'm using the JMS version of this, which is "QueueConnection.createQueueSession()". When I do this, however, it seems as if I lose control over the transaction.

    Ok, I think I've answered some of this for myself, but I still have some concerns.
    I see that the QueueSession object that I get back from "queueConnection.createQueueSession()" is likely going to actually be an instance of the "AQjmsSession" class, so I can cast to that, and then I can call "commit" or "rollback".
    What is unclear from the javadoc description is what happens when "close()" is called on the session object. Does this do an implicit "commit()", perhaps unless "rollback()" has already been called?
    I'm still a little uncertain about whether the scope of my transaction will be wide enough to protect everything that needs to be protected.
    For instance, I assume that my transaction starts when my consumer (not in an application server) reads the message from the queue. At that point, my consumer does some "screen-scraping" work. When it's done, it will call a session bean on the application in the application server (separate JVM, in other words), which will create some EJB entity objects and also insert raw database rows. The session bean will then return, and then the original method which read a message from the queue will be completed.
    What I need to know is what will happen if ANYTHING in that process fails, either in the external consumer, or in the session bean, or creating EJB entities? That is, will the entire transaction be rolled back, undoing the EJB entity creations AND the removal of the message from the message queue?
    If this can possibly work, I'm assuming this would be utilizing an XA datasource, or a non-emulated data source (which I think means the same thing).

  • Can CMT Session Bean call BMP Entity Bean in WebLogic 6.0?

              Hi
              Does anybody successfully use CMT Session Bean calling BMP +CMT Entity bean in
              WebLogic6.0? I have the following problem.
              Any idea will be appreciated.
              --Winston
              Let's say we have a Session bean SB, it uses container to manage the transaction.
              A method of SB will call an Entity Bean EB which adopts bean-managed persistence.
              Both SB and EB use CMT and all of their methods use "required" in the descriptor
              file.
              1. If the connection con.getAutoCommit() is true in the EB, then the transaction
              within SB cannot be rolled back as the ejbCreate() has already commit into the
              database.
              2. On the other hand if Connecton of EB con.getAutoCommit() is false, then container
              cannot successfully commit the transaction from SB's method, as EjbCreate and
              EjbStore() in EB are likely using the different database connections, which causes
              EbjStore() fail and the following error message will be sent to the Console:
              ============================================================
              "<Jul 9, 2001 4:16:48 PM PDT> <Error> <EJB> <Exception during commit of transacti
              on transaction=(IdHash=7738920,Name = [EJB TraderBeanImpl.buy()],Xid=105:5e6719a
              ded42e332,Status=Rolled back. [Reason = weblogic.utils.NestedRuntimeException:
              E
              rror writing from beforeCompletion - with nested exception:
              [java.rmi.NoSuchObjectException: Exception from ejbStore:javax.ejb.NoSuchEntityE
              xception: ejbStore: AccountBean (4003) not updated]],numRepliesOwedMe=0,numRepli
              esOwedOthers=0,seconds since begin=0,seconds left=30,SCInfo[examplesServer]=(sta
              te=rolledback),properties=({weblogic.transaction.name=[EJB TraderBeanImpl.buy()]
              })): java.rmi.NoSuchObjectException: Exception from ejbStore:javax.ejb.NoSuchEnt
              ityException: ejbStore: AccountBean (4003) not updated
              at weblogic.ejb20.internal.EJBRuntimeUtils.throwRemoteException(EJBRunti
              meUtils.java:57)
              at weblogic.ejb20.manager.DBManager.beforeCompletion(DBManager.java:364)
              at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManag
              er.java:211)
              at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(Serv
              erSCInfo.java:511)
              at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(Se
              rverSCInfo.java:78)
              at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAn
              dChain(ServerTransactionImpl.java:893)
              at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(
              ServerTransactionImpl.java:1229)
              at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTran
              sactionImpl.java:168)
              at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:2
              01)
              at examples.ejb.basic.statefulSession.TraderBeanEOImpl.buy(TraderBeanEOI
              mpl.java:37)
              at examples.ejb.basic.statefulSession.TraderBeanEOImpl_WLSkel.invoke(Tra
              derBeanEOImpl_WLSkel.java:76)
              at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
              va:373)
              at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
              va:237)
              at weblogic.rmi.internal.BasicRequestHandler.handleRequest(BasicRequestH
              andler.java:118)
              at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest
              .java:17)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              --------------- nested within: ------------------
              weblogic.utils.NestedRuntimeException: Error writing from beforeCompletion - wit
              h nested exception:
              [java.rmi.NoSuchObjectException: Exception from ejbStore:javax.ejb.NoSuchEntityE
              xception: ejbStore: AccountBean (4003) not updated]
              at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManag
              er.java:220)
              at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(Serv
              erSCInfo.java:511)
              at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(Se
              rverSCInfo.java:78)
              at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAn
              dChain(ServerTransactionImpl.java:893)
              at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(
              ServerTransactionImpl.java:1229)
              at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTran
              sactionImpl.java:168)
              at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:2
              01)
              at examples.ejb.basic.statefulSession.TraderBeanEOImpl.buy(TraderBeanEOI
              mpl.java:37)
              at examples.ejb.basic.statefulSession.TraderBeanEOImpl_WLSkel.invoke(Tra
              derBeanEOImpl_WLSkel.java:76)
              at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
              va:373)
              at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
              va:237)
              at weblogic.rmi.internal.BasicRequestHandler.handleRequest(BasicRequestH
              andler.java:118)
              at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest
              .java:17)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              --------------- nested within: ------------------
              weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion
              : sync = weblogic.ejb20.internal.TxManager$TxListener@356eb0
              Error writing from beforeCompletion - with nested exception:
              [weblogic.utils.NestedRuntimeException: Error writing from beforeCompletion -
              wi
              th nested exception:
              [java.rmi.NoSuchObjectException: Exception from ejbStore:javax.ejb.NoSuchEntityE
              xception: ejbStore: AccountBean (4003) not updated]]
              at weblogic.transaction.internal.TransactionImpl.throwRollbackException(
              TransactionImpl.java:1261)
              at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTran
              sactionImpl.java:218)
              at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:2
              01)
              at examples.ejb.basic.statefulSession.TraderBeanEOImpl.buy(TraderBeanEOI
              mpl.java:37)
              at examples.ejb.basic.statefulSession.TraderBeanEOImpl_WLSkel.invoke(Tra
              derBeanEOImpl_WLSkel.java:76)
              at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
              va:373)
              at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
              va:237)
              at weblogic.rmi.internal.BasicRequestHandler.handleRequest(BasicRequestH
              andler.java:118)
              at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest
              .java:17)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              >"
              

    We did receive a 4.5.1 / 5.1 interoperability patch - but it wasn't quite 'seamless'.
    We never tried to use it.
    SOAP? Isn't that around 50 times slower than RMI?
    Mike
    "Gary Mui" <[email protected]> wrote:
    We ran into this issue last fall and got some feedback from weblogic
    support. They originally said that it could be done (as well as different
    versions talking to one another via JMS) but it turned out that they
    were
    incorrect and ended up saying that it is not possible. Before 6.0 went
    GA,
    BEA said that there would be a interoperability patch to do this, but
    I've
    never seen nor heard of anything regarding it. As a workaround, we
    implemented 4.5.1 / 6.0 communication via SOAP.
    Mike Reiche wrote in message <3b1bcaec$[email protected]>...
    I have the same question - and more. Last year we were told that wecould
    not use
    RMI (and ejbs) between 4.5.1 and 5.1. Which seems kinda weird becauseI've
    heard
    of people using WL ejbs from Tomcat. This issue has caused us to avoidusing
    WL ejbs in any future development which has any chance of ever beingused
    by any
    app server (WL included) that is not under the direct control of thedata
    center.
    I've been trying to convince the Architecture team here that we canuse WL
    EJBs
    and we can call them from other app servers - but can't seem to getany
    supporting
    statement from BEA (maybe I haven't tried hard enough).
    Anyway, a response from BEA would be appreciated.
    - Mike
    "Madhu K" <[email protected]> wrote:
    Is it possible to call a (stateless session) bean deployed in weblogic
    6.0
    from a bean in weblogic 5.1? I have two versions of weblogic running
    on two
    different hosts and I have to call a bean that is running in 6.0 from
    5.1.
    Are there any limitations?
    Appreciate any feedback/suggestions.
    Thanks,
    Madhu

  • 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

  • Transaction inside a stateful session bean

    I've a stateful session bean that represents a shopping cart.
    It has the following checkout method():
    <pre>
    /* em.getTransaction().begin(); */
    reasons.clear();
    for(CartEntry ce : entries){
    // get the book reference for the cart entry
    Book relbook = books.findById(ce.getBook().getId());
    if( ce.getQuantity()> relbook.getQuantity() ){
    reasons.add("Item not availabel in this quantity");
    // TODO: need to rollback
    /*em.getTransaction().rollback();*/
    throw new Exception();
    } else{
    // update book quantities
    relbook.setQuantity( relbook.getQuantity() - ce.getQuantity() );
    /*em.getTransaction().commit();*/
    // end of conversational state
    cancel();
    </pre>
    This method checks for the quantity of the items with respect to the quantity in the cart entries.
    How can I perform a transaction here?
    I'd like to rollback it before throwing the exception. And I'd like to commit it at the end,.
    If I use the entity manager to get the transaction, I get this error:
    Exception Description: Cannot use an EntityTransaction while using JTA.

    Its sad to see someone using EJB technology and then completely throw all benefits of it out of the window. I highly advise you to look into Container Managed Transactions; learn what they help you to do and then apply it. When you know how, it will put a smile on your face as you'll see the transaction management stuff disappear before your eyes.
    , from the time by which I decrement the item quantity in the database to the commit, no other transaction is decrementing the quantity of the same item as well??? Am I protected against this???Concurrency is a hard problem with no clearly defined answers to it other than "you need to design the code to guard against concurrency problems". In this specific case, the database protects against this happening by applying a row lock or a table lock while the transaction is active and you are making modifications. For more information about that, you should consult the documentation relating to your specific DBMS.

  • Cannot remove stateful session bean when transaction timed out

    The transaction timeout is set to 5 minutes. After several operations on the transactional
    stateful session bean(implements SessionSynchronization), the transaction timed out
    after 5 minutes and I got the IllegalStateException when calling another business
    method. After the transaction rolled back, weblogic.ejb20.locks.LockTimedOutException
    was thrown when attempting to remove the bean. It seems the lock on the bean was
    not released even though the transaction had been rolled back. Does anyone know how
    to remove the bean in this kind of situation?
    Here is the stacktrace:
    ####<Jun 11, 2002 2:39:35 PM PDT> <Notice> <EJB> <app1x.zaplet.cc> <server25044server>
    <ExecuteThread: '11' for queue: 'default'> <> <23168:7b09681c532dc7e3> <010015> <Error
    marking transaction for rollback: java.lang.IllegalStateException: Cannot mark the
    transaction for rollback. xid=23168:7b09681c532dc7e3, status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException:
    Transaction timed out after 299 seconds
    Xid=23168:7b09681c532dc7e3(3203140),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
    since begin=299,seconds left=60,activeThread=Thread[ExecuteThread: '11' for queue:
    'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[server25044+server25044server]=(state=active),properties=({weblogic.jdbc=t3://10.0.100.93:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=server25044server+10.0.100.93:7001+server25044+,
    Resources={})],CoordinatorURL=server25044server+10.0.100.93:7001+server25044+)]>
    java.lang.IllegalStateException: Cannot mark the transaction for rollback. xid=23168:7b09681c532dc7e3,
    status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction
    timed out after 299 seconds
    Xid=23168:7b09681c532dc7e3(3203140),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
    since begin=299,seconds left=60,activeThread=Thread[ExecuteThread: '11' for queue:
    'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[server25044+server25044server]=(state=active),properties=({weblogic.jdbc=t3://10.0.100.93:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=server25044server+10.0.100.93:7001+server25044+,
    Resources={})],CoordinatorURL=server25044server+10.0.100.93:7001+server25044+)]
         at weblogic.transaction.internal.TransactionImpl.throwIllegalStateException(TransactionImpl.java:1486)
         at weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:466)
         at weblogic.ejb20.manager.BaseEJBManager.handleSystemException(BaseEJBManager.java:255)
         at weblogic.ejb20.manager.BaseEJBManager.setupTxListener(BaseEJBManager.java:215)
         at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:371)
         at weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:117)
         at weblogic.ejb20.internal.StatefulEJBObject.preInvoke(StatefulEJBObject.java:169)
         at mypackage.MyBean_wbr3eg_EOImpl.addRecipients(MyBean_wbr3eg_EOImpl.java:450)
    ####<Jun 11, 2002 2:39:37 PM PDT> <Info> <EJB> <app1x.zaplet.cc> <server25044server>
    <ExecuteThread: '11' for queue: 'default'> <> <> <010049> <EJB Exception in method:
    remove: weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:AppmailBean
    with primary key:21,775,960,933,010,237 timed-out after waiting 0 ms. The transaction
    or thread requesting the lock was:Thread[ExecuteThread: '11' for queue: 'default',5,Thread
    Group for Queue: 'default'].>
    weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:AppmailBean
    with primary key:21,775,960,933,010,237 timed-out after waiting 0 ms. The transaction
    or thread requesting the lock was:Thread[ExecuteThread: '11' for queue: 'default',5,Thread
    Group for Queue: 'default'].
         at weblogic.ejb20.locks.ExclusiveLockManager$LockBucket.lock(ExclusiveLockManager.java:448)
         at weblogic.ejb20.locks.ExclusiveLockManager.lock(ExclusiveLockManager.java:258)
         at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:226)
         at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:216)
         at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:310)
         at weblogic.ejb20.manager.StatefulSessionManager.remove(StatefulSessionManager.java:754)
         at weblogic.ejb20.internal.StatefulEJBObject.remove(StatefulEJBObject.java:86)
         at mypackage.MyBean_wbr3eg_EOImpl.remove(MyBean_wbr3eg_EOImpl.java:7308)

    If a stateful session throws a RuntimeException (your rollback) the container destroys the instance of the bean and all
    associated state information is lost, as required by the EJB specification.
    If you want to maintain client state it is generally best to use HttpSession objects (if you have a web application)
    for short-lived, client-specific data and JPA entities or other database backed storage for long-lived data.

Maybe you are looking for