Contaner managed transaction, when XA transaction completed?

Hi,
I used container managed transaction. And i wanna understand when a XA transaction is considered "started" and when it is "ended" ?
suppose, the application flow is:
from JSF GUI -> Managed Bean -> JMS -> EJB -> Database.
is there any differences if the application flow like this:
from JSF GUI -> Managed Bean -> JMS1 -> EJB -> JMS2 -> EJB -> JMS3 -> Database.
How many XA transactions are there in this case?
Could you suggest if there is around tutorial to start with XA transaction?
thanks,
Edited by: CardM on Nov 2, 2012 12:38 AM

CardM wrote:
Hi,
I used container managed transaction. And i wanna understand when a XA transaction is considered "started" and when it is "ended" ?
suppose, the application flow is:
from JSF GUI -> Managed Bean -> JMS -> EJB -> Database.Those are at least two isolated transactions. Everything up to and including sending a message and everything upon receiving one. Likely the transactions happen in two different and isolated containers too.

Similar Messages

  • MDB Container Managed Transaction and Log4J

    Hi,
    I'm programming and MDB that reads and updates a database then sends out an HTTP Post and logs using log4j. I've read that when an MDB is configured as CMT or container managed transaction and the OnMessage method executes without errors, the transaction is implicitly commited. You can rollback the transaction by explicitly calling setRollbackOnly() or when a RuntimeException has been thrown. My worry is that after I have sent out an HTTP POST (a transaction has been completed) I would have to log a transaction completion using log4j. My problems is if log4j throws a RuntimeException thereby rolling back my transaction which shouldn't be the case. What I have done is to catch all Exceptions (and swallow them) whenever I log using log4j after I have sent out an HTTP POST succesfully (since my transaction should be complete by then). Is this a correct workaround?
    Thanks :)

    Your approach is correct. If you think, Log4J might throw errors, swallow the exceptions and try not to roll back.

  • MDB container managed transaction demarcation not working in wls 6.1 beta

    I have an MDB which sends the messages it receives onto another JMS
              destination within the onMessage method. These messages are not sent to
              the JMS destination unless I explicitly use a transacted session for the
              destination and subsequently commit the session. If I set the transacted
              parameter to Session as false the messages are sent. If I set the
              transacted parameter to true the messages will only be output if the
              session is committed. This is the standard behaviour for a JMS session
              but this is not the correct behaviour for an MDB running with
              container-managed transaction demarcation.
              For a start the transacted parameter to session should be ignored when
              run in the context of a container transaction and the commit method
              should thrown an exception as it is not allowed within the context of a
              container transaction.
              This is the MDB code and the deployment descriptor: -
              public class MessageBean implements MessageDrivenBean, MessageListener
              private String topicName = null;
              private TopicConnectionFactory topicConnectionFactory = null;
              private TopicConnection topicConnection = null;
              private TopicSession topicSession = null;
              private Topic topic = null;
              private TopicPublisher topicPublisher = null;
              private TextMessage textMessage=null;
              private transient MessageDrivenContext messageDrivenContext = null;
              private Context jndiContext;
              public final static String
              JMS_FACTORY="weblogic.examples.jms.TopicConnectionFactory";
              public final static String
              TOPIC="weblogic.examples.jms.exampleTopic";
              public MessageBean()
              public void setMessageDrivenContext(MessageDrivenContext
              messageDrivenContext)
              this.messageDrivenContext = messageDrivenContext;
              public void ejbCreate()
              public void onMessage(Message inMessage)
              try
              jndiContext = new InitialContext();
              topicConnectionFactory =
              (TopicConnectionFactory)jndiContext.lookup(JMS_FACTORY);
              topic = (Topic) jndiContext.lookup(TOPIC);
              topicConnection =
              topicConnectionFactory.createTopicConnection();
              topicConnection.start();
              // The transacted parameter should be ignored in the context of a
              container tx
              topicSession = topicConnection.createTopicSession(true,
              Session.AUTO_ACKNOWLEDGE);
              topicPublisher = topicSession.createPublisher(topic);
              textMessage = (TextMessage)inMessage;
              topicPublisher.publish(inMessage);
              // this is illegal in a container transaction
              topicSession.commit();
              topicConnection.close();
              catch (JMSException je)
              throw new EJBException(je);
              catch (NamingException ne)
              throw new EJBException(ne);
              public void ejbRemove()
              <?xml version="1.0" encoding="UTF-8"?>
              <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
              JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
              <ejb-jar>
              <enterprise-beans>
              <message-driven>
              <display-name>MessageBean</display-name>
              <ejb-name>MessageBean</ejb-name>
              <ejb-class>MessageBean</ejb-class>
              <transaction-type>Container</transaction-type>
              <message-driven-destination>
              <destination-type>javax.jms.Queue</destination-type>
              </message-driven-destination>
              <security-identity>
              <description></description>
              <run-as>
              <description></description>
              <role-name></role-name>
              </run-as>
              </security-identity>
              </message-driven>
              </enterprise-beans>
              <assembly-descriptor>
              <container-transaction>
              <method>
              <ejb-name>MessageBean</ejb-name>
              <method-name>*</method-name>
              </method>
              <trans-attribute>Required</trans-attribute>
              </container-transaction>
              </assembly-descriptor>
              </ejb-jar>
              

    Please see the response in the EJB newsgroup.
              Also, could you kindly only post to a single newsgroup?
              Thanks.
              "Jimmy Johns" <[email protected]> wrote in message
              news:[email protected]...
              > I have an MDB which sends the messages it receives onto another JMS
              > destination within the onMessage method. These messages are not sent to
              > the JMS destination unless I explicitly use a transacted session for the
              >
              > destination and subsequently commit the session. If I set the transacted
              >
              > parameter to Session as false the messages are sent. If I set the
              > transacted parameter to true the messages will only be output if the
              > session is committed. This is the standard behaviour for a JMS session
              > but this is not the correct behaviour for an MDB running with
              > container-managed transaction demarcation.
              >
              > For a start the transacted parameter to session should be ignored when
              > run in the context of a container transaction and the commit method
              > should thrown an exception as it is not allowed within the context of a
              > container transaction.
              >
              > This is the MDB code and the deployment descriptor: -
              >
              > public class MessageBean implements MessageDrivenBean, MessageListener
              > {
              > private String topicName = null;
              > private TopicConnectionFactory topicConnectionFactory = null;
              > private TopicConnection topicConnection = null;
              > private TopicSession topicSession = null;
              > private Topic topic = null;
              > private TopicPublisher topicPublisher = null;
              > private TextMessage textMessage=null;
              > private transient MessageDrivenContext messageDrivenContext = null;
              >
              > private Context jndiContext;
              >
              > public final static String
              > JMS_FACTORY="weblogic.examples.jms.TopicConnectionFactory";
              > public final static String
              > TOPIC="weblogic.examples.jms.exampleTopic";
              >
              > public MessageBean()
              > {
              > }
              >
              > public void setMessageDrivenContext(MessageDrivenContext
              > messageDrivenContext)
              > {
              > this.messageDrivenContext = messageDrivenContext;
              > }
              >
              > public void ejbCreate()
              > {
              > }
              >
              > public void onMessage(Message inMessage)
              > {
              > try
              > {
              > jndiContext = new InitialContext();
              > topicConnectionFactory =
              > (TopicConnectionFactory)jndiContext.lookup(JMS_FACTORY);
              > topic = (Topic) jndiContext.lookup(TOPIC);
              > topicConnection =
              > topicConnectionFactory.createTopicConnection();
              > topicConnection.start();
              > // The transacted parameter should be ignored in the context of a
              > container tx
              > topicSession = topicConnection.createTopicSession(true,
              > Session.AUTO_ACKNOWLEDGE);
              > topicPublisher = topicSession.createPublisher(topic);
              > textMessage = (TextMessage)inMessage;
              > topicPublisher.publish(inMessage);
              > // this is illegal in a container transaction
              > topicSession.commit();
              > topicConnection.close();
              > }
              > catch (JMSException je)
              > {
              > throw new EJBException(je);
              > }
              > catch (NamingException ne)
              > {
              > throw new EJBException(ne);
              > }
              > }
              >
              > public void ejbRemove()
              > {
              > }
              > }
              >
              >
              >
              >
              > <?xml version="1.0" encoding="UTF-8"?>
              >
              > <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
              > JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
              >
              > <ejb-jar>
              > <enterprise-beans>
              > <message-driven>
              > <display-name>MessageBean</display-name>
              > <ejb-name>MessageBean</ejb-name>
              > <ejb-class>MessageBean</ejb-class>
              > <transaction-type>Container</transaction-type>
              > <message-driven-destination>
              > <destination-type>javax.jms.Queue</destination-type>
              > </message-driven-destination>
              > <security-identity>
              > <description></description>
              > <run-as>
              > <description></description>
              > <role-name></role-name>
              > </run-as>
              > </security-identity>
              > </message-driven>
              > </enterprise-beans>
              > <assembly-descriptor>
              > <container-transaction>
              > <method>
              > <ejb-name>MessageBean</ejb-name>
              > <method-name>*</method-name>
              > </method>
              > <trans-attribute>Required</trans-attribute>
              > </container-transaction>
              > </assembly-descriptor>
              > </ejb-jar>
              >
              >
              >
              >
              >
              >
              >
              >
              

  • No externally managed transaction is currently active for this thread

    Got the following exception after updating an entity bean and call persist method. Code the given below the exception.
    Exception [TOPLINK-23010] (Oracle TopLink - 10g Release 3 (10.1.3.0.0) (Build 060118)): oracle.toplink.exceptions.TransactionException
    Exception Description: No externally managed transaction is currently active for this thread
    public Object persistEntity(Object entity) {
    em.flush();
    em.persist(entity);
    return entity;
    private void modifyUser (Iuser user, String newHandle, Hashtable userDetails) throws UnknownException, WarningException {
    if (user == null) {
    throw new WarningException (new CatalogHelper("ITOOLS_000015", "to modify a user"));
    boolean handleUpdate = false;
    if ((newHandle != null) && !newHandle.equals("^\\s*$")) {
    handleUpdate = true;
    String oldHandle = user.getUserhandle();
    if (handleUpdate && oldHandle.equalsIgnoreCase(newHandle)) {
    handleUpdate = false;
    if (!handleUpdate && (userDetails == null) || (userDetails.size() == 0)) {
    return;
    if (handleUpdate) {
    userDetails.put("userhandle", newHandle);
    IToolsUtil.validateInputData("iuser", userDetails, false);
    if (handleUpdate) {
    userDetails.remove("userhandle");
    System.out.println("handleUpdate " + handleUpdate);
    // For User admin, handle, isactive, isadmin cannot be changed.
    if (oldHandle.equals("admin")) {
    if (handleUpdate) {
    throw new WarningException (new CatalogHelper("ITOOLS_000045", "Handle"));
    String active = (String)userDetails.get("isactive");
    if ((active != null) && !active.equals("Yes")) {
    throw new WarningException (new CatalogHelper("ITOOLS_000045", "Is Active"));
    String admin = (String)userDetails.get("isadmin");
    if ((admin != null) && !admin.equals("Yes")) {
    throw new WarningException (new CatalogHelper("ITOOLS_000045", "Is Admin"));
    System.out.println("user transaction started");
    if (handleUpdate) {
    FinderMethods fm = new FinderMethods();
    try {
    fm.findByUserHandle(em, newHandle);
    throw new WarningException (new CatalogHelper("ITOOLS_000043", newHandle));
    } catch (ObjectNotFoundException onfe) {
    user.setUserhandle(newHandle);
    System.out.println("User handle modified");
    } catch (SQLException se) {
    se.printStackTrace();
    throw new UnknownException (new CatalogHelper("ITOOLS_100000", new Object[]{"modifyUser", se.getMessage()}));
    String lname = (String)userDetails.get("userlname");
    if (lname != null) {
    user.setUserlname(lname);
    String fname = (String)userDetails.get("userfname");
    if (fname != null) {
    user.setUserfname(fname);
    String email = (String)userDetails.get("useremail");
    if (email != null) {
    user.setUseremail(email);
    String passwd = (String)userDetails.get("userpasswd");
    if (passwd != null) {
    user.setUserpasswd(passwd);
    String active = (String)userDetails.get("isactive");
    if (active != null) {
    user.setIsactive(active);
    String admin = (String)userDetails.get("isadmin");
    if (admin != null) {
    user.setIsactive(admin);
    System.out.println("details are updated");
    persistEntity(user);
    System.out.println("committed");
    How to resolve this issue? I am using Jdeveloper 10.1.3.0.4 (SU4)
    regds
    -raju

    The stack trace is given below. This exception is occured at "em.flush()" method. I even tried removing em.flush() method. Even then I got the same exception.
    I tried a different way of overcome this problem. Used UserTransaction instance say "ut" before create / modify the entity bean and later comitted. In that case I am not getting any exceptions. However, commit is happening only when new instance is created, commit works, but modification of an existing instance, commit is not working. Looks like there is some serious problem with EJB 3.0 in OC4J. Basic functionality is not working.
    Stack trace when flush method is called:
    Local Exception Stack:
    Exception [TOPLINK-23010] (Oracle TopLink - 10g Release 3 (10.1.3.0.0) (Build 060118)): oracle.toplink.exceptions.TransactionException
    Exception Description: No externally managed transaction is currently active for this thread
         at oracle.toplink.exceptions.TransactionException.externalTransactionNotActive(TransactionException.java:98)
         at oracle.toplink.internal.ejb.cmp3.transaction.base.JTATransactionWrapper.checkForTransaction(JTATransactionWrapper.java:39)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.checkForTransaction(EntityManagerImpl.java:322)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.getActiveUnitOfWork(EntityManagerImpl.java:314)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.flush(EntityManagerImpl.java:164)
         at com.itools.vs.model.session.AdminSessionBean.persistEntity(AdminSessionBean.java:57)
         at com.itools.vs.model.session.AdminSessionBean.createUser(AdminSessionBean.java:124)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)
    Stack trace when persist method is called:
    Local Exception Stack:
    Exception [TOPLINK-23010] (Oracle TopLink - 10g Release 3 (10.1.3.0.0) (Build 060118)): oracle.toplink.exceptions.TransactionException
    Exception Description: No externally managed transaction is currently active for this thread
         at oracle.toplink.exceptions.TransactionException.externalTransactionNotActive(TransactionException.java:98)
         at oracle.toplink.internal.ejb.cmp3.transaction.base.JTATransactionWrapper.checkForTransaction(JTATransactionWrapper.java:39)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.checkForTransaction(EntityManagerImpl.java:322)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.getActiveUnitOfWork(EntityManagerImpl.java:314)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.persist(EntityManagerImpl.java:74)
         at com.itools.vs.model.session.AdminSessionBean.persistEntity(AdminSessionBean.java:57)
         at com.itools.vs.model.session.AdminSessionBean.createUser(AdminSessionBean.java:123)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)

  • Container-managed / bean-managed transaction demarcation

    I am trying to make sure I understand container-managed and bean-managed transaction demarcation and in particular where you have one bean calling another bean. What happens where one of the beans has container-managed transaction demarcation and the other bean-managed transaction demarcation. In fact the initial question to ask is, is this allowed?
    Lets use an application scenario to illustrate the issue. The application has a payment transaction. Payments can be received in one of two ways:
    1. As a payment at a branch where the individual payment is processed on a client application and resulting in the processing of a single payment transaction.
    2. As a batch of payments received from a bank containing, potentially, thousands of payment transactions.
    The proposed implementation for this uses two session beans. The first is a Payment session bean that implements the business logic as appropriate calling entity beans to persist the change. The second is a BatchPayment session bean. This processes the batch of payment transactions received from the bank. The BatchPayment reads through the batch of payments from a bank calling the Payment session bean for each payment transaction.
    Lets look at the transactional properties of both session beans. In order to support the client application the Payment session bean can implicitly enforce transactional integrity and is therefore set to container-managed transaction demarcation. However the BatchPayment session bean will want to explicitly specify transaction demarcation for performance reasons. The transactional "commit" process is relatively expensive. When processing a large batch of transactions rather than performing a commit after every transaction is processed we want to perform the commit after a number of transactions have been processed. For example, we may decide that after every 100 transactions have been processed we commit. The processing will have a shorter elapsed time as we have not had to perform 99 commit processes. So the BatchPayment session bean will want to explicitly specify its transaction demarcation and will therefore be defined with bean-managed transaction demarcation.
    How would this be implemented? A possible solution is:
    Payment session bean implemented with container-managed transaction demarcation with transaction scope set to Required.
    BatchPayment session bean implemented with bean-managed transaction demarcation with transaction scope set to Required.
    When the client application is run it calls the Payment bean and the container-managed transaction demarcation ensures the transactional integrity of that transaction.
    When a BatchPayment process is run it explicitly determines the transaction demarcation. Lets say that after every 100 Payment transactions (through 100 calls to the Payment session bean) have been processed the BatchPayment bean issues a commit. In this scenario however we have mixed container-managed and bean-managed transaction demarcation. Hence my original question. Can container-managed and bean-managed transaction demarcation be mixed? If not how is it possible to implement the requirements as described above?
    Thanks for any thoughts.
    Paul

    BatchPayment session bean implemented with bean-managed transaction demarcation with transaction scope set to Required.Didn't quite understand this sentence.... if it's BMT it has no declarative transaction attributes such as "Required"....
    Anyway, first of all I'll have to ask, Why at all would you want to commit in the middle of the business method? to get as much through as possible before a potential crash? :-)
    Can container-managed and bean-managed transaction demarcation be mixed?Yes, of course. Just remember that the "direction" you are refering to ->
    a BMT SB that propagates it's transaction to a method in a CMT SB that is demarcated with "Required" is the simplest case. If it were "reversed", or for that matter any BMT that might be called within an active transaction context must perform logic to manipulate the transaction state. For instance(and most common case), checking to see if a transaction is active and if so not to do anything(just use the one that is already active).
    If not how is it possible to implement the requirements as described above?You could also implement this scenario with CMTs all the way through. your BatchPayment SB could consist of two methods, one (say, execute(Collection paymentsToExecute) ) with "Supports", and another(say executeBatchUnit(Collection paymentsToExecute, int beginIndex, int endIndex) ) with "RequiresNew".
    then have the first just call the other with indexes denoting each time a group of payments.
    Still, it does seem more suitable using BMT for these kind of things.....
    Hope this helped....

  • Container managed transactions in 9.0.3 (plus AQ JMS/MDB)

    Something for "real programmers", similar to MDB Transaction Exception on OC4J 9.0.4 (MDB Transaction Exception on OC4J 9.0.4) but little bit different. Maybe author of the mentioned thread can find some answers here also.
    We have an MDB accessing AQ in database (this works either with 9i and 8i). MDB receives the message (actually TextMessage), retrieves the content/properties and calls some EJBs making database operations. When we used just the same DataSource for JMS resource provider and SQL operations, everything worked OK. But we need to move one step further - making calls to several databases, some 8i, some might 9i. We were able to start CMT for one DataSource, i. e. configuring OrionCMTDataSource over JDBC ORACLE driver (if you use different DataSource class, message remains stucked in queue and eventually expires. If you don't specify container managed transactions for MDB in ejb-jar.xml, it works with any DataSource class - but message is lost every time exception occurs - not very pleasant situation).
    We are trying to configure DataSources so they provide transactional support while using commit coordinator. There are some documents describing this - in 9iAS Data Sources and JTA, Orion Data Sources and possibly JTA description in 9i database documentation. Both ORACLE documents are very similar. Generally, these are main steps:
    1) configure each data source so they provides CMT support (wrap native driver/data source by OrionCMTDataSource class)
    2) create datasource commit-coordinator database, also using CMT(?)
    3) create user in commit-coordinator database and same in each other database with connect, resource, create session + force any transaction priviledge (since it would commit other users transactions)
    4) create database links from commit-coordinator database to each databases (but... see questions below)
    5) configure commit coordinator so it uses proper data source
    6) add each DB link as a property to data sources
    7) configure data source for JMS
    8) connect JMS resource provider with JMS data source
    9) Start container, send message, etc.
    So far the only result we've got is a trace file in database user dumps and generic "javax.transaction.SystemExeption: Could not commit: error code 29540". User dump occurs in a "remote" database, not the one where commit coordinator resides. If I drop database links, result is the same, so it seems like problem with data source itself. In a dump there is piece of text like this: "FATAL ERROR IN TWO-TASK SERVER: error = 12571" and "ksedmp: internal or fatal error
    Current SQL statement for this session:
    begin dbms_aqin.aq$_dequeue_in( :1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19, :20, :21, :22, :23, :24, :25, :26, :27, :28, :29); end; ". I think AQ call is just a coincidence since it is the first one involved in transactions. Down there in HEX part of a dump there is a message about protocol or network error ("probably ORA-28546")
    Here is an example of data source configuration we are using:
    <!-- Passport CMT DataSource -->
    <data-source
    name="PassportDS"
    class="com.evermind.sql.OrionCMTDataSource"
    location="jdbc/PassportDS"
    connection-driver="oracle.jdbc.driver.OracleDriver"
    username="int"
    password="int"
    url="jdbc:oracle:thin:@ws18885:1521:ICON"
    inactivity-timeout="30">
    <property name="dblink" value="ICON.WS18885.APPG.COM"/>
    There are some questions pending. Obvious one is if CMT is working or not at all and we should find some different solution (Bean managed transactions or use XA, hmmm). Other one might be that database link has to be "fully-qualified". I'm not sure what it means: using username and password? Using database name along with domain (if any)? So far it seems links are not used anyway.
    We've tried several databases, like 9.2.0.1 and 9.0.3 versions. Result is the same.
    We've tried to use XA data source of ORACLE (oracle.jdbc.xa.client.OracleXADataSource) and OrionCMT data source bound by xa-source-location to it but container gets stucked upon restart with "Investingating resource 'XADataSource PassportXADS' for recovery..." and similar messages for an hour.
    There is an OracleJTADataSource mentioned in several documents, but I cannot find any in jdbc classes - was it deprecated?
    Lies the problem in JMS itself? So far we've been able to use AQ in 8i and 9i and succesfully commit every transaction - provided transaction was local.
    Since XA itself is working I guess problem might be with configuration.
    I will appreciate any opinion on CMT... also, if you have any questions, please ask.
    Myrra

    Hi Per,
    I don't have an answer for you -- sorry {:-( -- only a suggestion (which
    you may have already tried, anyway :-). Have you tried running OC4J
    in "debug" mode? The following web-page gives details on how to do that:
    http://kb.atlassian.com/content/atlassian/howto/orionproperties.jsp
    Also, if you aren't already aware of them, the following web-sites
    may also be helpful (not in any particular order):
    http://www.orionserver.com
    http://www.orionsupport.com
    http://www.elephantwalker.com
    Good Luck,
    Avi.

  • JTA Container Managed Transaction Demarcation question?

    Hello, there is something I'm not quite sure about, concerning JTA Container managed transaction
    I have a remote stateful session bean with a method f().
    the method f() calls the methods g() and h() residing in a different stateless local bean DBLocalBean.
    (DBLocalBean only deals with database calls using the EntityManager)
    I would like to know where the commit is being executed? after f() or after g() and h()

    Hi Meir,
    It depends on the exact settings of the container managed transaction attributes. The most typical (and default) transaction attribute is TX_REQUIRED. TX_REQUIRED means that when a business method invocation arrives the container will either a) import any existing propagated client transaction context or b) if one is not available, start a new transaction.
    Assuming TX_REQUIRED for the three business methods in your example, the container would start a new transaction before invoking f() . Both g() and h() would execute in that same transaction since f's transaction would propagate to them. Finally, after f() returns, the container would commit the transaction it started.
    --ken                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • Bean-Managed Transaction and xDoclet

    Hi,
    i am new by xDoclet.
    Does anybody know, how to specify Bean-Managed Transaction by EJB using xDoclet.
    Thank you very much for any hint or link.
    --Eugen                                                                                                                                                                                                                                                                                                                           

    Thanks Dhiraj for helping,
    I have a application module called TestAppModule. TestAppModule should be deployed as Bean Managed Service Bean. In the Remote of the Application Module, I chose BmtServiceBean. 3 files were created
    RemoteTestAppModule.java
    TestAppModuleHome.java
    TestAppModuleServer.java
    In ejb-jar.xml, this tag was added
    <enterprise-beans>
    <session>
    <description>Session Bean ( Stateful )</description>
    <display-name>TestAppModule</display-name>
    <ejb-name>testBc4jComponents.TestAppModule_bmservice</ejb-name>
    <home>testBc4jComponents.common.serviceejb.beanmanaged.TestAppModuleHome</home>
    <remote>testBc4jComponents.common.serviceejb.beanmanaged.RemoteTestAppModule</remote>
    <ejb-class>testBc4jComponents.server.serviceejb.beanmanaged.TestAppModuleServer</ejb-class>
    <session-type>Stateful</session-type>
    <transaction-type>Bean</transaction-type>
    </session>
    </enterprise-beans>
    In Orion-ejb-jar.xml
    <session-deployment name="testBc4jComponents.TestAppModule_bmservice"/>
    I deployed the bean into oc4j.
    In the Bean Where I am managing the Transaction.
    Context ctx = new InitialContext();
    Object home = ctx.lookup("testBc4jComponents.TestAppModule_bmservice");
    TestAppModuleHome testAppHome = (TestAppModuleHome) PortableRemoteObject.narrow(home, TestAppModuleHome.class);
    When I am looking up the Appmodule Bean, I reached an error stating "Serialization Error, The TestAppModuleImpl is not Serializable"
    Please let me know what I am doing wrong?
    Thanks
    Senthil

  • Container Managed Transactions

    Hi everyone
    I've been reading some documentation about Container Managed Transactions and I am not sure if I understood the actual meaning of the "required" attribute.
    Imagine one user calls a method (whith "required") wich joins a transaction. If another user calls the same method at the same the transaction is running, that means this method joins the same transaction of the other user? Or this only happen if the first user calls another "required" method?
    Thanks

    If another user calls the
    same method at the same the transaction is running,
    that means this method joins the same transaction of
    the other user? Or this only happen if the first user
    calls another "required" method?
    Not sure what you mean. First a txn of one user is isolated from the txn of another (remember the ACID props of txns). So a given txn spawn by one user can never be 'joined' by another.
    What 'required' means is that, for one given user, if a txn is in progress already from a method (method 1) when another method (method2) is called, method2 joins the txn in method1; if there were no txn in method1, a new txn is started in method2.

  • Bean Managed Transactions and rollback

    Hi Everybody,
    I am using Bean Managed Transactions in a Message Bean which is called every some time by an EJB3 timer. This Message Bean subsequently calls a Session Bean which uses Container Managed Transactions and uses the default transaction attribute which is SUPPORTS. The Session Bean methods might sometime throw a System Exception(inheriting from RuntimeException) which will rollback the Bean Managed Transaction which was started from the Message Bean.
    When this happens and I try to invoke userTransaction.rollback() I get invalid transaction state exception and I suppose this means that is already rolled back.
    Is there a way to get another transaction or set the transaction back to a valid state so I can carry on with some persistence tasks or the only way to do that is by suppressing the RuntimeException and throwing an Application Exception having the *@ApplicationException(rollback=false)* annotation? Can I suppress a System Exception though?
    Thank you in advance!

    Saroj wrote:
    Hi All,
    I would like to know whether we can use JDBC Connection Object's commit and rollback
    methods to control Transaction in Bean Managed Transactions or not.You may use the JDBC connection's transaction support from an EJB. That being said, you
    need to understand that it won't be the transaction that started declaratively by the
    EJB container nor would it be a bean-managed transaction started through
    UserTransaction.
    FWIW, I question why you'd want to do this though. I'd use container-managed
    transactions and let the container handle this for you. The transaction manager
    includes a 1PC optimization so it's not going to do an XA/2PC tx if you only have a
    single resource in the tx. Also, the EJB container includes all the logic to properly
    handle rollbacks when exceptions are thrown etc.
    Finally, your code will more maintainable and reusable if you use the container-managed
    tx + JTA resources. If I later wanted to call another EJB or another JTA resource (eg
    JMS perhaps) I could do it without having to rewrite all of your code.
    -- Rob
    >
    >
    Why is it required that we should use Java Transaction API to control the Transaction
    in Our Beans?
    I understand that if we are using Multiple Resources and need to use Transaction
    then going for JTA makes sense. If I am using only Resource,for example, Only One
    Connection then we should be able to use Connection's Transaction control.
    I understand that other way to do the transaction is to use Container's transaction
    services.
    Please respond at the earliest.
    Thanks in Advance,
    Saroj

  • Java.sql.SQLException: You cannot commit during a managed transaction!

    Hi all,
    I'm just trying to get the tutorial Car EJP app to work with Jboss 3.2.1
    When creating a new car record by calling the car.edit() method it reaches
    the line
    pm.makePersistent (car);
    and then throws the exception
    com.solarmetric.kodo.runtime.FatalDataStoreException:
    com.solarmetric.kodo.runtime.FatalDataStoreException:
    java.sql.SQLException: You cannot commit during a managed transaction!
    [code=0;state=null]
    When checking the jboss log, it is clear that kodo is trying to commit the
    sequence update :
    at
    org.jboss.resource.adapter.jdbc.WrappedConnection.commit(WrappedConnection.java:477)
    at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.commit(SQLExecutionManagerImpl.java:783)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory.updateSequence(DBSequenceFactory.java:267)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory.getNext(DBSequenceFactory.java:111)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.newDataStoreId(JDBCStoreManager.java:598)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.makePersistentFilter(PersistenceManagerImpl.java:1418)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.makePersistent(PersistenceManagerImpl.java:1348)
    at com.titan.kodojdotest.ejb.CarBean.edit(CarBean.java:51)
    How should i get this to work ????
    tx for your help,
    Roger.

    It appears that you are using ConnectionFactoryName. First be sure to
    set a ConnectionFactory2Name which will be a non-transactional (in terms
    of global transaction) DataSource for sequence generation for which you
    are seeing here. There are also some issues with JBoss's connection
    pooling on certain dbs if you are still seeing the problem after this.
    If so, try setting ConnectionURL, ConnectionPassword, etc explicitly
    Roger Laenen wrote:
    Hi all,
    I'm just trying to get the tutorial Car EJP app to work with Jboss 3.2.1
    When creating a new car record by calling the car.edit() method it reaches
    the line
    pm.makePersistent (car);
    and then throws the exception
    com.solarmetric.kodo.runtime.FatalDataStoreException:
    com.solarmetric.kodo.runtime.FatalDataStoreException:
    java.sql.SQLException: You cannot commit during a managed transaction!
    [code=0;state=null]
    When checking the jboss log, it is clear that kodo is trying to commit the
    sequence update :
    at
    org.jboss.resource.adapter.jdbc.WrappedConnection.commit(WrappedConnection.java:477)
    at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.commit(SQLExecutionManagerImpl.java:783)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory.updateSequence(DBSequenceFactory.java:267)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory.getNext(DBSequenceFactory.java:111)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.newDataStoreId(JDBCStoreManager.java:598)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.makePersistentFilter(PersistenceManagerImpl.java:1418)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.makePersistent(PersistenceManagerImpl.java:1348)
    at com.titan.kodojdotest.ejb.CarBean.edit(CarBean.java:51)
    How should i get this to work ????
    tx for your help,
    Roger.
    Steve Kim
    [email protected]
    SolarMetric Inc.
    http://www.solarmetric.com

  • Mass Change in Recipe management (Transaction RMWB) - change specification

    Hello ALL,
    I am working on a Requirement - Mass Change in Recipe management (Transaction RMWB)
    Requirement - for a given specification number get the list of all recipes where this particular specification is used (this is achieved by standard functionality in RMWB)
    When a particular recipe is changed in a recipe - perform a mass change of specification across all the recipes.
    Things I have found already:
    This has to be done in similar fashion as status change is done using ABAP Class -CL_RCP_MSC_STATUS
    I would appreciate your help and suggestion in this.
    Regards,
    Nikhil

    Hi Beth,
    Yeah actually we did the same thing per your specs: non-status related although confined to preferred recipes, substituting substance X for Y in dependent formulas of recipes.
    The only option right I am aware of currently requires custom ABAP work using the Mass-Change framework supplied. 
    Regards

  • FRM-40400: Transaction complete: 1 records applied and saved

    Dear All,
    Hope all of you are doing well,
    Pls go through my problem...
    here is an application developed based on Oracle Forms & Reports 6i.
    I wrote a code, like for some specific Users, various permissions.
    Ex: User A (Payroll Person), User B (HR)
    for employee Master Data HR is the right person to modify master data and all the remain are not permissible.
    I query one person (from Non HR user), try to modify Master Data  then it given user defined message -
    "you are not authorized person to modify Master Data" [OK] - so no changes done
    then I clicked the Query button directly,
    it gave the message - "Do you want to save the changes you have made"  [Yes] [No] [Cancel]
    when I clicked Yes :
    " FRM - 40400 : Transaction complete : 1 records applied and saved "
    In database also it is saving the record..
    Mean for unotherised user also It's modifying the data.
    Please help me the way to handle this issue..
    Thanks in Advance...

    As salamualikum, Md Sirajoddin
    You wrote
    I query one person (from Non HR user), try to modify Master Data  then it given user defined message -
    "you are not authorized person to modify Master Data" [OK] - so no changes done
    That means your code works in some condition. Right ?
    Place your code at Pre-Commit trigger at form level.
    Hope this helps
    Hamid

  • Can i user UserTransaction  in a Container-managed transaction Bean

    can i use UserTransaction to control transaction boundaries in a container-managed transaction bean method?
    below is the method:
    there is one-to-many between Employees and SalaryItem
    @TransactionAttribute(value = TransactionAttributeType.REQUIRED)
    private void initEmployeesSalary(Long salarySumId) {
    for(Employees employees: liEmployees){
    for (int i = 0; i < 20; i++) {                                                           
    SalaryItem item = new SalaryDetailItem();
    employees.addSalaryItem(item);
    when there are about 1000 employees,the method run very slow.
    What do you think I should do?
    null

    Hi again,
    The EJB specs say that a stateful Session Bean with CMT is NOT allowed to use the UserTransaction; see page 361 of the EJB2.0 specification. So combining them will not (or should not) work.
    I suggest CMT+SessionSynchronization combined with using a flag to indicate whether notify should be called or not. Otherwise, you could try splitting up the bean into two beans: one with CMT and another one without. The one without CMT could use the UserTransaction and notify.
    Also, you might want to check http://www.onjava.com/pub/a/onjava/2001/10/02/ejb.html
    Hope that helps a bit,
    Guy
    http://www.atomikos.com

  • Executing SQL statements in container managed transactions

    I have a problem when using TopLink 9.0.3 with WebSphere 4, Oracle 9i and J2EE container managed transactions.
    The data changing SQL statements are executed at the end of the (container managed) transaction, not at the time of the calls to UnitOfWork.registerNewObjekt(),
    UnitOfWork.validate...() or UnitOfWork.commit...().
    UnitOfWork(2035008996)--validate object space.
    UnitOfWork(2035008996)--validate cache.
    UnitOfWork(2035008996)--JTS#beforeCompletion()
    UnitOfWork(2035008996)--Connection(398132708)--INSERT INTO SVM_PERSONEN (FAX, NAME, ID, [...]) VALUES ([...])
    UnitOfWork(2035008996)--JTS#afterCompletion(org.omg.CosTransactions.Status._StatusRolledBack=4)
    UnitOfWork(2035008996)--release unit of work
    But the end of the transaction is out of the application server code. The transaction ends after the invoke of the applixcation server method, as the stack trace of an occurring exception shows:
    remote exception
    javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0 No; nested exception is:
         org.omg.CORBA.TRANSACTION_ROLLEDBACK:
    org.omg.CORBA.TRANSACTION_ROLLEDBACK: com.ibm.websphere.csi.CSITransactionRolledbackException:
         at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:194)
         at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:67)
         at com.ibm.ejs.csi.TransactionControlImpl.postInvoke(TransactionControlImpl.java:414)
         at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:1818)
         at de.gedas.svm.server.app.ejb.EJSRemoteStatelessNavigationEJB.findPersonenZulieferer(EJSRemoteStatelessNavigationEJB.java:964)
         at de.gedas.svm.server.app.ejb._EJSRemoteStatelessNavigationEJB_Tie._invoke(_EJSRemoteStatelessNavigationEJB_Tie.java:589)
         at com.ibm.CORBA.iiop.ExtendedServerDelegate.dispatch(ExtendedServerDelegate.java:506)
         at com.ibm.CORBA.iiop.ORB.process(ORB.java:2376)
         at com.ibm.CORBA.iiop.OrbWorker.run(OrbWorker.java:186)
         at com.ibm.ejs.oa.pool.ThreadPool$PooledWorker.run(ThreadPool.java:104)
         at com.ibm.ws.util.CachedThread.run(ThreadPool.java:137)
    So the application server code has no possiblity for special reaction to this error condition.
    How can I use TopLink to execute my SQL statement immidately, not at the the end of the transaction (which is out of the area of my code)? Only the transaction should end at the usual time, managed by the container.

    I don't think there is anyway to currently do this in a JTS managed environment, to handle the exceptions you could,
    - Make use of TopLink session ExceptionHandlers to handle the database errors during the JTS commit.
    i.e.
    uow.setExceptionHandler(yourExceptionHandler);
    or,
    - Let TopLink control the transactions instead of JTS.

Maybe you are looking for