EJB testing out of container - Ejb3Unit + transaction support?

I want to use JUnit for some EJB testing and have been looking at EJB3Unit for this. But then I heard that transactions are supported, it this true? If not, good. If true, how do you solve this?

Hi Debu,
I searched OTN. I could not find the example you have mentioned. Every time I got the example for a very previous release of OC4J.
Please help me locate the example you are referring to.
Thanks
Vikrant.

Similar Messages

Best practice for @EJB injection in junit test (out-of-container) ?

Hi all,
I'd like to run a JUnit test for a Stateless bean A which has another bean B injected via the @EJB annotation. Both beans are pure EJB 3 POJOs.
The JUnit test should run out-of-container and is not meant to be an EJB client, either.
What is the easiest/suggested way of getting this injection happening without explicitely having to instantiate the bean B in my test setup ?

you can deal with EntityBeans without having the Container managed senario , you can obtain instance of EntityManager using the "EntityManagerFactory" and providing the "persistence.xml" file and provide the "provider" (toplink,hibernate ,...), then you can use entities as plain un managed classes

About Container-managed Transactions and Bean-managed Transactions

as the document of weblogic7.0 describe the differents of Container-managed
          Transactions and Bean-managed Transactions,and in the document,It tell us
          details of using Bean-managed Transactions,such as \:
          import javax.naming.*;import javax.transaction.UserTransaction;.....
          import java.sql.*;import java.util.*;
          UserTransaction tx = (UserTransaction)
          ctx.lookup("javax.transaction.UserTransaction");tx.begin();
          tx.commit() //or tx.rollback
          but how to use Container-managed Transactions?
          what is EJB's deployment descriptor? can someone tell me?
          i wonder someone will show me an example of how to use Container-managed
          Transactions.
          thanks
          fish


Many if not all of the WLS EJB examples use container-managed
          transactions. That's a good place to start.
          I'd also recommend that you pick up a decent EJB book. There's several
          on the market right now.
          -- Rob
          fish wrote:
          > <ejb-jar>
          > <enterprise-beans>
          > <session>
          > <ejb-name>testbean</ejb-name>
          > <home>test.test.TestHome</home>
          > <remote>test.test.Test</remote>
          > <ejb-class>test.test.TestBean</ejb-class>
          > <session-type>Stateful</session-type>
          > <transaction-type>Container</transaction-type>
          > </session>
          > </enterprise-beans>
          >
          > <assembly-descriptor>
          > <container-transaction>
          > <method>
          > <ejb-name>EmployeeRecord</ejb-name>
          > <method-name>*</method-name>
          > </method>
          > <trans-attribute>Required</trans-attribute>
          > </container-transaction>
          > </assembly-descriptor>
          > </ejb-jar>
          > ----------------------------------------------
          > seems i have to write ejb-jar.xml like this,am i right?
          > what about <ejb-client-jar>? is it needed in this xml file?
          >
          > thanks
          >
          > fish
          >
          >

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:

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

JMS Sender with ejb3 container managed transaction

Hi all,
I refer to the following link http://download.oracle.com/docs/cd/E11035_01/wls100/jms/trans.html#wp1035937
I found that JTA support JMS.
But I dont' want to use JTA explicitly, I want to use container manage transaction. eg. inside ejb3 stateless session bean.
does it support JMS?
With Regards,
wp

Hi,
Yes, WebLogic JMS supports JTA (a.k.a XA, a.k.a global) transactions such as container managed transactions. There are two requirements for CMTs on SSB:
(1) use an XML descriptor setting or EJB annotation to enable CMT for the SSB
(2) use a WebLogic JMS connection factory that is configured to have "global (XA) transactions enabled"
And I usually also recommend:
(3) Consider using a JEE "res-ref" for the connection factory to enable pooling of JMS resources. See "Enhanced Support for Using WebLogic JMS with EJBs and Servlets" (http://download.oracle.com/docs/cd/E14571_01/web.1111/e13727/j2ee.htm#g1329180), and the "Integrating Remote JMS Providers" FAQ (http://download.oracle.com/docs/cd/E14571_01/web.1111/e13727/interop.htm#JMSPG553).
(4) Avoid using SSBs to receive messages. MDBs are specifically designed for processing incoming messages.
It's also possible to have WebLogic automatically enlist foreign (non-WebLogic) vendors in WebLogic transactions. See the "Integrating Remote JMS Providers" FAQ for details (http://download.oracle.com/docs/cd/E14571_01/web.1111/e13727/interop.htm#JMSPG553).
Regards,
tom

Local transaction support when BPEL invokes JCA adapter

Hi all,
I've implemented a BPEL process consisting of multiple invoke activities to my (custom) JCA Resource Adapter which connects to an EIS.
My concern is to support local transactions. Here are some code snippets describing what I've done so far.
Declare the transaction support at deployment time (ra.xml)
<transaction-support>LocalTransaction</transaction-support>Implementer class of ManagedConnection interface
public class MyManagedConnection implements ManagedConnection {
     public XAResource getXAResource() throws ResourceException {
         throw new NotSupportedException("XA Transactions not supported");
     public LocalTransaction getLocalTransaction() throws ResourceException {
         return new MyLocalTransaction(this);
        public void sendTheEvent(int eventType, Object connectionHandle) {
             ConnectionEvent event = new ConnectionEvent(this, eventType);
             if (connectionHandle != null) {
                event.setConnectionHandle(connectionHandle);
            ConnectionEventListener listener = getEventListener();
         switch (eventType) {
          case ConnectionEvent.CONNECTION_CLOSED:
               listener.connectionClosed(event); break;
          case ConnectionEvent.LOCAL_TRANSACTION_STARTED:
               listener.localTransactionStarted(event); break;
          case ConnectionEvent.LOCAL_TRANSACTION_COMMITTED:
               listener.localTransactionCommitted(event); break;
          case ConnectionEvent.LOCAL_TRANSACTION_ROLLEDBACK:
               listener.localTransactionRolledback(event); break;
          case ConnectionEvent.CONNECTION_ERROR_OCCURRED:
               listener.connectionErrorOccurred(event); break;
          default: break;
}Implementer class of LocalTransaction interface
public class MyLocalTransaction implements javax.resource.spi.LocalTransaction {
     private MyManagedConnection mc = null;
     public MyLocalTransaction(MyManagedConnection mc) {
         this.mc = mc;
     @Overide
     public void begin() throws ResourceException {
         mc.sendTheEvent(ConnectionEvent.LOCAL_TRANSACTION_STARTED, mc);
     @Override
     public void commit() throws ResourceException {
         eis.commit(); //eis specific method
         mc.sendTheEvent(ConnectionEvent.LOCAL_TRANSACTION_COMMITTED, mc);
     @Override
     public void rollback() throws ResourceException {
         eis.rollback(); //eis specific method
         mc.sendTheEvent(ConnectionEvent.LOCAL_TRANSACTION_ROLLEDBACK, mc);
}Uppon BPEL process completion, MyLocalTransaction.commit() is called. However, localTransactionCommitted(event) fails and I get the following error:
Error committing transaction:; nested exception is: weblogic.transaction.nonxa.NonXAException: java.lang.IllegalStateException:
[Connector:199175]This ManagedConnection is managed by container for its transactional behavior and has been enlisted to JTA transaction by container;
application/adapter must not call the local transaction begin/commit/rollback API. Reject event LOCAL_TRANSACTION_COMMITTED from adapter.Could someone give me some directions to proceed ?
My current installation consists of:
1. Oracle SOA Suite / JDeveoper 11g (11.1.1.4.0),
2. WebLogic Server 10.3.4
Thank you for your time,
George

Hi Vlad, thank you again for your immediate response.
With regards to your first comment. I already have been using logs, so I confirm that neither javax.resource.spi.LocalTransaction#begin() nor javax.resource.spi.LocalTransaction#commit()
is called in the 2nd run.
I think it might be helpful for our discussion if I give you the call trace for a successful (the first one) run.
After I deploy my custom JCA Resource Adapter, I create a javax.resource.cci.ConnectionFactory through Oracle EM web application and the following methods are called:
-- MyManagedConnectionFactory()
(Constructor of the implementer class of the javax.resource.spi.ManagedConnectionFactory interface)
-- javax.resource.spi.ManagedConnectionFactory#createManagedConnection(javax.security.auth.Subject, javax.resource.spi.ConnectionRequestInfo)
-- MyManagedConnection()
(Constructor of the implementer class of the javax.resource.spi.ManagedConnection interface)
-- javax.resource.spi.ManagedConnection#addConnectionEventListener(javax.resource.spi.ConnectionEventListener)
-- javax.resource.spi.ManagedConnection#getLocalTransaction()
-- MySpiLocalTransaction(MyManagedConnection)
(Constructor of the implementer class of the javax.resource.spi.LocalTransaction interface)
-- javax.resource.spi.ManagedConnectionFactory#createConnectionFactory(javax.resource.spi.ConnectionManager)
-- MyConnectionFactory(javax.resource.spi.ManagedConnectionFactory, javax.resource.spi.ConnectionManager)
(Constructor of the implementer class of the javax.resource.cci.ConnectionFactory interface)BPEL process consists of multiple invoke activities to my (custom) JCA Resource Adapter which connects to an EIS. Client tester invokes BPEL process, and execution starts.
Here is the method call trace for the last invoke (after which, commit is executed). The logs for all the rest invocations are identical:
-- javax.resource.cci.ConnectionFactory#getConnection()
-- javax.resource.spi.ManagedConnection#getConnection(javax.security.auth.Subject, javax.resource.spi.ConnectionRequestInfo)
-- MyConnection(MyManagedConnection)
(Constructor of the implementer class of the javax.resource.cci.Connection interface)
-- javax.resource.cci.Connection#close()
(I don't understand why close() is called here, any idea ?)
-- javax.resource.cci.ConnectionFactory#getConnection()
-- javax.resource.spi.ManagedConnection#getConnection(javax.security.auth.Subject, javax.resource.spi.ConnectionRequestInfo)
-- MyConnection(MyManagedConnection)
(Constructor of the implementer class of the javax.resource.cci.Connection interface)
-- javax.resource.cci.Connection#createInteraction()
-- MyInteraction(javax.resource.cci.Connection)
(Constructor of the implementer class of the javax.resource.cci.Interaction interface)
-- javax.resource.cci.Interaction#execute(javax.resource.cci.InteractionSpec, javax.resource.cci.Record, javax.resource.cci.Record)
-- javax.resource.spi.LocalTransaction#commit()I would expect that after the last commit() - meaning that BPEL process is done, and its state is "Completed" - Weblogic server would call the following:
javax.resource.cci.Connection#close()However it doesn't. Do I miss something ?

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.

Container-Managed Transaction Type Attributes not working as expected

I am having a problem with the container-managed transactions not working as expected. I have 2 methods that work as follows:
MethodA{
for(a lot)
call MethodB;
@Transaction Type = RequiresNew
MethodB{
EntityManager Persist to database
I want the code in MethodB to be committed to the database when methodB returns. The problem is that I am running out of memory and MethodA is failing. When methodA fails after numerous calls to MethodB nothing is persisted to the database.
It is my understanding that when using requires new transactions that a new transaction is started for each call to the method and ends when the method returns while the calling method transaction is suspended.
How am I misunderstanding the requiresNew transaction attribute. What can I do to make a batch insert into my database that will not run out of memory (commit when a methodB returns)?
Thanks in advance.

The problem is that EJB invocation semantics for security, container-managed transactions, etc.
only apply when an invocation is made through an EJB reference. In your case, you are directly
invoking the implementation method from within the bean. The EJB container has no idea that's
happening. It's no different than invoking a utility method.
In order to get the behavior you'd like, you need to retrieve a reference to your own bean and invoke
through that. You can use SessionContext.getBusinessObject() to get the EJB reference for the
business interface through which the method in question is exposed.
--ken

Ejbload() on CMP with transaction = supports - why called before every method?

If an entity bean (CMP v2) has its transaction attrib "supports", why
when a client (ejb/servlet/jsp) calls its business methods does WLS
call ejbLoad() before every method call? Note that the calls do not
occur inside a transaction!
This is not intuitive to me. I would think that ejbLoad() would be
called once when the bean is activated and then all business methods would
access that data.
Note that if you put the entity bean behind a session bean with a
transaction attrib "Required", then the ejbLoad() gets called once no
matter how many business methods are called from the session bean.
This is (obivously) correct.
Why is this relevant? The latest java petstore demo essentially calls
EJBLocal's from jsp (via taglib's) - I guess no different from WLS
EJB to taglib product - where the fine grained getter methods are
called. From what I gather, this means that every one of the jsp
get methods results in a database read! This can't be right!
What am I missing? As above, if the entity bean has "supports"
and is called from a jsp, it appears that ejbLoad()/ejbStore()
would be called for every jsp taglib invocation.
Glenn

"Glenn R. Kronschnabl" wrote:
Rob,
Thanks for your reply. This implies that even EJBLocals with fine
grained getter methods should never be used outside a tx scope.Yes, unless you are using Read-Only entity beans which cache data for longer
periods of time.
Even
though you bypass the RMI semantics, you'll be killed by the local tx.
Which to me says that using EJB's from JSP (even via tags) is a bad
idea because each getter method will result in a database read/write,
(unless you go with a readonly EJB as you stated).
Accessing transactional entity beans via tags is probably a bit off. You
could start the tx in the JSP or the tag library, but I don't really like
that pattern much. I prefer making the tags more coarse-grained and having
the tags talk to a stateless session bean which in turn talks to the entity
beans.
>
Unfortunately, I've been seeing some threads on the net advocating
using EJBLocals with tx=supports because one of the most common
patterns has session beans (where you can specify your desired tx)
in front of entity beans (so you're set methods are protected via
the session bean tx),RIght, I think Required or Mandatory is a better choice for the entity beans
here.
but then you can use the EJBLocal (via tags)
on a JSP page (no tx) to view the data via fine grained getter
methods.Other than the performance issues, I dislike this because it exposes the
entity bean directly to the JSP. If I have to go through an interface (the
session bean) to access the entity bean, then I shouldn't have another route
to access the entity bean directly.
-- Rob
>
As you state, this is a disaster because each getter method
will run in a local tx, requiring a database read/write. Oouch!
Glenn
On Thu, 06 Dec 2001 17:08:07 -0600, Rob Woollen wrote:
First off, I wouldn't recommend that you ever run any EJB with the
'supports' transaction attribute. If you want transactional behavior
use Required, RequiresNew, or Mandatory. If you want to run in an
unspecified tx, use NotSupported or Never.
WLS runs entity beans with an unspecified tx in their own local tx.
That's why you see the reads and writes on the method call boundary.
Your scheme of only reading when the bean is activated could make the
bean's data out of sync with the underlying database. That's acceptable
in many cases, and that's why we have the Read-Only entity bean option.
It gives you exactly what you'd like.
-- Rob
"Glenn R. Kronschnabl" wrote:
If an entity bean (CMP v2) has its transaction attrib "supports", why
when a client (ejb/servlet/jsp) calls its business methods does WLS
call ejbLoad() before every method call? Note that the calls do
not occur inside a transaction!
This is not intuitive to me. I would think that ejbLoad() would be
called once when the bean is activated and then all business methods
would access that data.
Note that if you put the entity bean behind a session bean with a
transaction attrib "Required", then the ejbLoad() gets called once no
matter how many business methods are called from the session bean. This
is (obivously) correct.
Why is this relevant? The latest java petstore demo essentially calls
EJBLocal's from jsp (via taglib's) - I guess no different from WLS EJB
to taglib product - where the fine grained getter methods are called.
From what I gather, this means that every one of the jsp get methods
results in a database read! This can't be right! What am I missing? As
above, if the entity bean has "supports" and is called from a jsp, it
appears that ejbLoad()/ejbStore() would be called for every jsp taglib
invocation.
Glenn
AVAILABLE NOW!: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnWebLogic.com
[att1.html]

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

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.

Entity Bean can only use container-managed transaction demarcation?

In <<Designing Enterprise Application with J2EE 2nd>>
Section 2.3.3.3 Enterprise Bean Transactions,it says:Entity beans can only use container-managed transaction demarcation.
That means,i can not get UserTransaction from EJBContext.
Is that true?

Yes this is the requirement of the specs. Your ejb code generator should give you the error if you use usertransaction.
--Ashwani

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

Enable Oracle XA Transaction Support

Hi everybody. First of all, sorry for my terrible English.
I've been some problems using COM+ with Personal Oracle 8i (8.1.7.0.0) and SQL Server 2000 and Windows 2000 for development only.
I have one method that inserts the same data both SQL Server and Oracle (the tables and procedures definitions are identical) and I'm utilizing GetObjectContext method to commit or abort the transactions (the COM component were made in VB). Out of COM+ environment the method works 5x5. The error message is: "-2147168229 - Cannot connect to the transaction manager or the transaction manager is unavailable."
Checking Microsoft documentation I found an article (http://support.microsoft.com/support/complus/mtsandoracle.asp) telling me to "Enable Oracle XA Transaction Support" so I could have transactional work with Oracle and COM+. OK, just fine.
Does anyone knows how could I manage it? I am not a DBA nor I know one (an Oracle DBA), but I shall explain to my team how program 2 phase commit between Oracle and SQL Server.
Thanks in advance, and forgive me the size of this "book". I should be shorter next time...
null

Vivek, thanks for the help.
I am utilizing these versions of Oracle Products:
Personal Oracle8i Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
Net8 Client 8.1.7.0.0
Oracle Services for MTS 8.1.7.0.0
Oracle Provider for OLE DB 8.1.7.2.0
The provider I first tried was MSDAORA with no success and then ORAOLEDB with no success too.
But those entries in registry that you sent me were all with Microsoft dll`s. I will try again tomorrow and send you the results
Thank you again
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Vivek Raja:
Renato, firstly what is the interface you use to access Oracle from your COM+ components? If it is OLEDB which provider is in use - MSDAORA or ORAOLEDB? What are the versions in use 8.1.6 or 8.1.7? If you are using MSDAORA as the provider then you will need to add the following key to your registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\MTxOCI.
Under this key add the following registry string values:
OracleOCILib - oraclient8.dll
OracleXALib - oraclient8.dll
OracleSQLLib - orasql8.dll
If you are using ORAOLEDB as the provider install Oracle Services For MTS 8.1.7. The error you receive seems to point to the fact that the "Distributed Transaction Coordinator" Windows2000 Service is not running.<HR></BLOCKQUOTE>
null

Refresh object in container managed transaction

i am using container managed transactions on my ejbs which in turn invoke toplink persistence services. consider the scenario where a record which is inserted has its primary key - a sequence generated number. i want to return this id to the calling module after committing. but as this is a CMT case, the commit doesn't really happen on uow.commit() and thus the object that i return back doesn't have the primary key.
in a two-tier scenario, i find that the primary key is available right after commit for obvious reasons.
is there a way to achieve this. how do i return the primary key or even the whole object about to be inserted to the caller ???

I am assuming you are mapping POJO and not entity beans.
The UnitOfWork has API that allows you to have the PK sequence values assigned prior to commit.
UnitOfWork.assignSequenceNumber(Object)
http://download-west.oracle.com/docs/cd/B10464_01/web.904/b10491/oracle/toplink/sessions/UnitOfWork.html#assignSequenceNumber(java.lang.Object)
UnitOfWork.assignSequenceNumbers()
I hope this addresses your issue.
Doug

EJB testing out of container - Ejb3Unit + transaction support?

Similar Messages

Maybe you are looking for