MDB container transaction

          Hi,
          I had a MDB running quite happily to check for database changes. Because the MDB
          deleted entries form a log table when it had read them I added a container managed
          transaction for the onMessage function. Now I keep getting a Warning message:
          Message Driven Bean 'UpdateCheck' is transacted but the provider defined in the
          ejb is not transacted. Provider should be transacted if onMessage method in MDB
          is transacted.
          I cannot find out what the "Provider" referred to is. I have used the default
          ConnectionFactory - do I need to create my own to enable transactions?
          Peter.

The provider in this case is JMS, and for whatever reason it is not capable of using
          transactions.
          If you are using WL JMS, just don't specify a
          ConnectionFactory inside the descriptor files so that the MDB uses the
          default WL MDB connection factory. If you insist on specifying a connection
          factory, ensure it is one that has "user transactions enabled".
          If you are not using WL JMS, that is whole new ball of wax. Look for
          the white-paper on integrating foreign JMS providers on dev2dev.bea.com
          for answers.
          Tom
          Peter Hughes wrote:
          > Hi,
          > I had a MDB running quite happily to check for database changes. Because the MDB
          > deleted entries form a log table when it had read them I added a container managed
          > transaction for the onMessage function. Now I keep getting a Warning message:
          >
          > Message Driven Bean 'UpdateCheck' is transacted but the provider defined in the
          > ejb is not transacted. Provider should be transacted if onMessage method in MDB
          > is transacted.
          >
          > I cannot find out what the "Provider" referred to is. I have used the default
          > ConnectionFactory - do I need to create my own to enable transactions?
          >
          > Peter.

Similar Messages

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

Unknown assembly-descriptor subtag container-transaction

I am getting this error message when I try to deploy my EJB application to 9iAS v2 via OEM. I can remove all "container-transaction" references from orion-ejb-jar.xml and deploy the app, then add the references later and it works just fine.
Any ideas?

Thanks Rob. That's what I was hoping to hear. I agree with you on the need
          to explicitly define the tx attribute. In the absence of any tools for
          validating the attributes, chances are that errors like these can go
          un-noticed and hence it helps to know the behavior upfront.
          BTW, it was nice meeting you at San Diego.
          Regards,
          Adarsh
          "Rob Woollen" <[email protected]> wrote in message
          news:[email protected]..
          > I believe it will default to NotSupported.
          >
          > That being said, I'd highly recommend that you always set a transaction
          > attribute explicitly instead of relying on container defaults.
          >
          > -- Rob
          >
          > Adarsh Dattani wrote:
          >
          > > In my WLS 6.0 ejb-jar.xml if I set the tx type to container
          > > <transaction-type>Container</transaction-type> ) and omit the
          > > <container-transaction> element within the <assembly-descriptor>
          element,
          > > how does the container handle the transaction within the onMessage
          method of
          > > my MDB ? Does it assume Required, NotSupported or neither ?
          > >
          > > --
          > > Regards,
          > > Adarsh
          >

Will weblogic support 2 Phase support for MDB (Container Managed)

The Transaction is not rolling back when i am throwing an EJB exception during the update of the database
          Followed the below steps
          0) Created a XAConnectionPool (Oracle XA thin Driver)
          1) Created a DataSource for the above pool
          2) Created a QueueConnection factory with XA checked
          3) Deployed a MDB with Transaction Support as Required
          4) When the Database is throwing an exception the message is not rolled back /
          Any idea why this is happening?Will Weblogic 81 supports Container Management for MDB for 2PC transactions?
          i have Oracle driver in the weblogic start classpath and using getting the connection to the DB from the weblogic pool

- Of course WebLogic supports 2PC - and has for years.
          - There's no need to configure a JMS connection factory - the MDB's default choice is transaction capable.
          - See MDB doc for details on how to configure transactional MDBs.
          (hint: two descriptor settings are required)
          http://edocs.bea.com/wls/docs81/ejb/message_beans.html
          - FYI: You may want to consider upgrading to 9.1:
          * Can pause MDBs
          * Can pause destinations
          * Can view individual messages on the console
          * much higher file store performance
          * JDBC LLR option (faster than pure XA 2PC)
          * MDB transaction batching (speeds up XA - documentation is missing but will be in place soon)

Omitting container-transaction in ejb-jar.xml

Hi,
This may be an easy answer (although I'm struggling to find onejust now) but if you don't define a <container-transaction> element to the ejb-jar.xml for your EJBs, what transaction attribute is used when using Container Managed Persistence? Are transactions used at all it this scenario or does it default to auto committing after every statement?
Also, what part does the application server vendor play in this - if any?
Thanks in advance for any help on this topic.

I'm still struggling to get a conclusive answer to this issue. Read a few books and the EJB spec itself but nothing seems to give an answer on this issue. This makes me think that it is up to the container if it is not defined.
Also did some tests on Oracle 9ias and it seems that transactions aren't used when transaction config is not defined for CMT beans as it would only rollback on an error when it was defined. Still need to do some more tests.
Again, if anyone is able to help shed some light on this then it would be much appreciated.
Thanks.

How set autocommit=false with container transactions?

Hi all!
A'm using EJB's with transaction attribute=Container.
This is simple scenario:
call Session Bean
begin transaction
call EntityBean1 {
database update 1
call EntityBean2 {
database update 2
end transaction
return from session bean
The problem is:
when update2 fails update1 not rolling back.
A know, that solution of this problem is set AUTOCOMMIT=FALSE in Connection, but how do this with container transactions? Point me exactly to place, where this can be done, if this possible. Or may be no general solution (I.e. Each case demands it's own approach.)?
(I can't directly call method of Connection object because of transaction managed by container)
Tnx a lot.

Hi there,
I have the same problem with Orion and NuSphere MySql.
When I define a container-managed transaction, the autocommit mode is not changed.
I have a session bean for which I set the transaction attribute to REQUIRED and two entity beans for which the transaction attribute is SUPPORTS in the ejbjar.xml file.
The session beans calls the two entity beans and makes some modifications on them like for instance removing them from the database.
When I check whether a transaction can be rolled back, for instance by putting in my code a loop that never ends and then stopping the server, it seems my application is running in autocommit mode. No rollback is done.
This is very strange.
The two entity beans are stored using gemini tables which permit rollbacks. So when I start a transaction inside mySql using sql statements, I can do a rollback without problem.
Any idea of what's going wrong ?
Dimitri.

MDB,MDB container or JMS adapter stops processing messages from JMS queue

Hi guys,
we have created a component using Enterprise Java Beans, let's say a product catalog, deployed it on a Glassfish v2 instance, and connected it to a legacy system using JMS and Sun MQ v4.1 as messaging system. The catalog component thus starts one MDB that listens on a JMS queue, let's say a queue named catalog_business_events_in, and waits for incoming messages, i.e. in our case update events. The problem is, that in general this approach works well, but sometimes the MDBs/JMS adapter stops for some reason fetching and processing messages from the JMS queue. We don't know why - no exceptions, etc.. Seems to be a Glassfish EJB container, JMS adapter or Sun MQ configuration issue. It seems to be that our component is not the problem.
The messages are compressed/uncompressed by Sun MQ automatically. We actually have 2 Sun MQ instances in clustered mode running to have some kind of failover - no HA cluster, yet. Sun MQ instances are accessed from Glassfish instances running in different Glassfish clusters - so we have a dedicated Sun MQ cluster not a Sun MQ instance per Glassfish instance. Each Glassfish instance is configured such that it knows both Sun MQ instances to allow automatic failover.
Has someone an idea, why the MDBs/ MDB container/ JMS adapter - stops processing messages? We are kind of puzzled as it happens more often now and apparently when traffic is (very) low not high!
Thanks for your help.
Cheers,
Martin
Edited by: east1979 on Jan 13, 2009 8:06 AM

Hi Manoj,
I have a very similar if not identical issue,
Error while running realtime jobs that read from JMS tables via JMS MQ adapter:
15/11/12 09:10:08 JMS GET OPERATION ERROR : TIMEOUT.UNABLE TO RECEIVE RESPONSE FROM THE INVOKED DATA SERVICES SERVICE.ADAPTER OPERA
TION TO CONTINUE.
15/11/12 09:10:15 Communication Error. See real time job log for details.
Dump available:
https://sapmats.wdf.sap.corp/download/download.cgi?id=5C0KZAHA3RSXBJW3ABLMUUT2P5UUKWO2TM3EJDM5W2HGDZUDID
Version of DS:14.0.3.273
Any comments?
Thansk and kind Regards,
Kenneth

EJB module Editor - Container Transactions bug report

When in "EJB module Editor" screen under the "Container Transactions" node following bugs happen:
1) I click on the "Add..." button
2) In the "Create Container Transaction Entry" screen I click on "Add method.." button.
3) Once "Define Method Entry" screen appears, I first have to clic on space to see the list of available EJB's (I have 13 of them) as the screen does not display the list! (for this bug the easiest it would be to send you a screen shot so that you can see)
4) After I selected the EJB I wanted, I choose "*" for all methods
5) Once returned to the "Create Container Transaction" Screen I click "Ok' and I can see that my Entry was added to the "Container Transaction Entries" list
6) I go the EJB I just added to the transction entries list, and select the "Methods" node and the frist selected methods will have the appropriate "Container Transaction" attribute set
7) If I select a different method or simply go back the "Container Transactions" node the EJB in question is not on the "Container Transaction" list any more!!!

Hi
I just followed your steps to reproduce the issues reported. I cannot reproduce the refresh issue as you mention in Step 3, but am able to reproduce the issue mentioned in step 7.
Logged bug 5124894 to track this issue
Thanks for pointing this out
Prasanth

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

Hello,
I was wondering if anyone else has experienced this problem and/or can suggest a solution...btw, I'm running this on JRun4.
I have a JMS queue that uses a database for the queue. The onMessage method for my MDB is part of a container managed transaction. My onMessage method simply inserts the message into an audit table. I then purposely change the name of the audit table so that my MDB will throw a SQLException.
If I send a single message, a SQL exception is thrown and caught and I roll back the transaction via MessageDrivenContext.setRollbackOnly(). The stdout logs show that after the exception the transaction is rolled back and the message is resent. This sequence occurs repeatedly until I fix the column name and then the message is consumed and inserted in my audit table. This works as I expect.
If I were to send 2 (or more) messages, the same SQL exception occurs for each message and the transaction is rolled back and the message(s) are resent. However, once I fix the table error, I find that those 2 messages were repeatedly consumed and inserted into the audit table (e.g. there were 50+ inserts). In the stdout logs it appears once the database problem is corrected each transaction that was rolled back now ends up commiting leading to repeat consumptions.
Has anyone encountered this? I'm a bit confused as to why, since the rollbacks, resends, and commits appear to work fine when there is only a single message.
Any suggestions? Thanks.

This is only a guess, but I'd say that the implementation isn't using two-phase commit aware resources (XAResources) to coordinate modifications to the backend database table. If you're only using a single resource (message in your case) then it's fine to use raw JDBC and turn auto-commit off; the application or container can then use the JDBC driver commit or rollback operations to make the change to the table happen (or not). If you're doing multiple updates through the same JDBC driver within the same global transaction then this still works.
I wonder if the implementation is somehow adding each message through a separate JDBC instance (even though to the same back end DM) and committing each prior to doing work on the next message. This commit may not be explicit. You may not even know it is going on: for example, if the back end db is Oracle, if you do a close on a JDBC connection which is running in a transaction then it will implicitly commit the transaction at that point.
For instance:
receive message
get JDBC connection
add message to table
close JDBC connection (may be explicit or may be implicit via the container)
<-- commit happens here in some cases
receive message
get JDBC connection
add message to table
What the implementation really should use is XADataSources and XAConnections to get XAResources that coordinate updates to the database. Or, make sure the same JDBC connection is used within the same transaction. This is more difficult to coordinate because of close.

MDB Distributed transaction and stored procedure rollback

Hi All,
I am developing an asynchronous application using MDB. My application flow is as follows:
1. From MDB onMessage i am calling another method MEthodA that
a. calls a simple pojo1 where I am getting a Connection on XA enable datasource1 and executing Stored Procedure1 of DatabaseSchema1. In Stored Procedure1 I have some inner savpoints and rollback. No commit is inside Stored Procedure1 .
b. In that pojo withput commiting m closing the connection and coming back in MethodA.
c. Again from MethodA m calling an different pojo2 where I am getting a new Connection on XA enable datasource2 and executing Stored Procedure2 of DatabaseSchema1.In this pojo also without commiting m closing the connection and coming back in MethodA. In Stored Procedure2 I have some inner savpoints and rollback. No commit is inside Stored Procedure2 .
d. Again from MethodA m calling pojo1 where I am getting a new Connection on XA enable datasource1 and executing a diffrent function of Stored Procedure1 of DatabaseSchema1.
Now problem is:
I have written some Savepoint and rollback inside Stored Procedure1 and inside Stored Procedure2. But these rollback is working only in inside Stored Procedure1 not in inside Stored Procedure2 in each case.
In ejb-jar.xml transaction attributes is Required for all methods and transaction type is Container.
Backend is Oracle 10g and init.xa has already been run on that.
I have tested this on Oc4J and Websphere 6.0.
I am using XaDatasource.
Will be very obliged if any one can give a single hint of the problem as soon as possible.
Thanks a lot

Hi Kent;
You have a few choices (AFAIK) with ASE...
1) AutoCommit = TRUE
- must be before connect to your DB
2) End your PB transaction first. For example
String ls_end = "END TRANSACTION"
String ls_begin = "BEGIN TRANSACTION"
EXECUTE IMMEDIATE ls_end using SQLCA;
<call your SP>
EXECUTE IMMEDIATE ls_begin using SQLCA;
3) use a 2nd Transaction Object for the SP where its AutoCommit = TRUE
- or -
4) In your SP ...
Commit Transaction
begin transaction
insert into mytab (pub_id) values ("9999")
commit transaction

Container transaction NOT rolled back after a long period of time.

Hi, I am using Weblogic 6.1SP5 on RedHat 7.1 and I have seen an unexpected
          behaviour with an MDB and I would like to know if there is any circumstance
          in which a transaction is not rolled back automatically by the container
          after the transaction timeout specified on MDB descriptor expired.
          The fact is I have seen a thread locked for 3 entire days without any
          exception being raised (the trans timeout was set to 900 seconds for
          debugging porpouses)
          Sadly I didn't thought on issuing a ps -ax and a netstat -np in order to see
          if there was any connection active for any of the JVM threads.
          As an aside note I had to throw a kill -9 to Weblogic's JVM in order to
          completely stop it because using the standard "stopWeblogic.sh" script it
          got stalled.
          The only unusual thing that I can think of the MDB is doing is opening a
          connection against a remote system via a socket.
          My question is. Is it possible that a thread locked on I/O (in this case a
          socket) to be out of control in terms of throwing at it a "Transaction
          rolled back exception"?
          I have modified my code in order to set SO_TIMEOUT on the socket just in
          case the other peer hangs and never returns control. But I would like to
          know the problem could be there.
          I know for sure that at the time the thread stalled the other peer died
          (exceptions on other MDBs trying to connect to remote system) but I expected
          a "socket exception" to be thrown by the O.S. to the stalled thread instead
          of having the thread waiting forever on that "open" socket.
          Thanks in advance.
          Ignacio.


While a tramsaction may be rolled back at the transaction timeout,
          the thread is not stopped. The actual exception won't occur until
          the MDB completes. If the MDB doesn't complete (as in this case),
          you won't get the exception.
          "Ignacio G. Dupont" <[email protected]> wrote in message news:[email protected]...
          > Hi, I am using Weblogic 6.1SP5 on RedHat 7.1 and I have seen an unexpected
          > behaviour with an MDB and I would like to know if there is any circumstance
          > in which a transaction is not rolled back automatically by the container
          > after the transaction timeout specified on MDB descriptor expired.
          >
          > The fact is I have seen a thread locked for 3 entire days without any
          > exception being raised (the trans timeout was set to 900 seconds for
          > debugging porpouses)
          >
          > Sadly I didn't thought on issuing a ps -ax and a netstat -np in order to see
          > if there was any connection active for any of the JVM threads.
          >
          > As an aside note I had to throw a kill -9 to Weblogic's JVM in order to
          > completely stop it because using the standard "stopWeblogic.sh" script it
          > got stalled.
          >
          > The only unusual thing that I can think of the MDB is doing is opening a
          > connection against a remote system via a socket.
          >
          > My question is. Is it possible that a thread locked on I/O (in this case a
          > socket) to be out of control in terms of throwing at it a "Transaction
          > rolled back exception"?
          >
          > I have modified my code in order to set SO_TIMEOUT on the socket just in
          > case the other peer hangs and never returns control. But I would like to
          > know the problem could be there.
          >
          > I know for sure that at the time the thread stalled the other peer died
          > (exceptions on other MDBs trying to connect to remote system) but I expected
          > a "socket exception" to be thrown by the O.S. to the stalled thread instead
          > of having the thread waiting forever on that "open" socket.
          >
          > Thanks in advance.
          >
          > Ignacio.
          >
          >

EJB 3.0 MDB and transactions

I'm trying to use an XA topic connection factory in my MDB, I was getting a "not supported in this release" error until I added this annotation to my MDB:
@MessageDrivenDeployment(
resourceAdapter = "myProviderInstance"
But now my MDB is no longer dequeuing messages.
I found the following in the docs (http://download-west.oracle.com/docs/cd/B31017_01/web.1013/b28221/undejdev010.htm#CCHGGHAE)
--- BEGIN QUOTE FROM ORACLE DOCS ---
If you use @MessageDrivenDeployment, you can configure message service options using nested @ActivationConfigProperty annotations or using @MessageDrivenDeployment attributes: @ActivationConfigProperty configuration overrides @MessageDrivenDeployment attributes.
If you use @MessageDriven, you can configure message service options using nested @ActivationConfigProperty annotations only.
If you configure using @MessageDrivenDeployment attributes, your application can only access a message service provider without a J2CA resource adapter. If later you decide to access your message service provider using a J2CA resource adapter, your application will fail to deploy. If you configure using nested @ActivationConfigProperty annotations, your application can access a message service provider with or without a J2CA resource adapter. Oracle recommends that if you configure using annotations, you should use the @ActivationConfigProperty approach.
Example 2-6 shows both a @MessageDrivenDeployment and @MessageDriven annotation using @ActivationConfigProperty annotations for message service configuration. Note that the DestinationName activation configuration property in the @MessageDrivenDeployment annotation overrides that in the @MessageDriven annotation.
Example 2-6 @MessageDriven and @MessageDrivenDeployment Annotation for a J2CA Message Service Provider
import javax.ejb.MessageDriven;
import oracle.j2ee.ejb.MessageDrivenDeployment;
import javax.ejb.ActivationConfigProperty;
import javax.jms.Message;
import javax.jms.MessageListener;
@MessageDriven(
activationConfig = {
@ActivationConfigProperty(
propertyName="DestinationName", propertyValue="OracleASjms/MyQueue"
@MessageDrivenDeployment(
activationConfig = {
@ActivationConfigProperty(
propertyName="DestinationName", propertyValue="OracleASjms/DeployedQueue"
@ActivationConfigProperty(
propertyName="ResourceAdapter", propertyValue="OracleASjms"
--- END QUOTE FROM ORACLE DOCS ---
So, instead of specifying the resource adapter as I had above, I simply pasted the last bit of annotations from the docs into my MDB, and much to my surprise I learned that you can't have an activationConfig in a @MessageDrivenDeployment
What's the solution?

OK, I got a little further. Everything works now as such
I'm using the XA topic connection factory, I'm using the resource adapter.
BUT, when I set the transaction required attribute on the MDB, I no longer receive messages.
No errors are logged anywhere. Any suggestions?

JMS publisher inheriting EJB container transaction

          I have trawled through the archives but just need to clarify :-
          How can I have an Session EJB which send messages to a JMS Queue inherit the EJB
          container managed transaction from the session bean, such that if the EJB rollsback
          the message will as well ?
          1) Firstly is this possible with container managed transactions ?
          2) Should I use a transacted (true) or non-transacted (false)
          Session ?
          queueConnection.createQueueSession(true,0); or
          queueConnection.createQueueSession(false,0); or
          3) Unless I call queueSession.commit() the message never seems to get there, but
          if I call commit() it seems to arrive at the MessageDriven bean IMMEDIATELY, i.e
          before the Session bean's transaction has committed. Do I need to commit() ?
          Any help would be appreciated.
          I have tried


          Pete wrote:
          > I have trawled through the archives but just need to clarify :-
          >
          > How can I have an Session EJB which send messages to a JMS Queue inherit the EJB
          > container managed transaction from the session bean, such that if the EJB rollsback
          > the message will as well ?
          >
          > 1) Firstly is this possible with container managed transactions ?
          Yes.
          > 2) Should I use a transacted (true) or non-transacted (false)
          > Session ?
          >
          > queueConnection.createQueueSession(true,0); or
          > queueConnection.createQueueSession(false,0); or
          >
          non-transacted, otherwise you will get the behavior in (3)
          ensure that the connection factory used has the
          "UserTransactionsEnabled" flag configured to true
          > 3) Unless I call queueSession.commit() the message never seems to get there, but
          > if I call commit() it seems to arrive at the MessageDriven bean IMMEDIATELY, i.e
          > before the Session bean's transaction has committed. Do I need to commit() ?
          >
          > Any help would be appreciated.
          > I have tried
          This is a frequently-asked question. See the JMS FAQ for details, also
          check out the tranaction chapter of the JMS programmer's guide, and, if
          your interested in performance considerations, check out the WebLogic
          JMS Performance Guide white-paper available on dev2dev.bea.com.

Re: container - transaction tag

Presently all methods of an entity bean run in a transaction. As a result each
method locks the entity bean there by making it unusable by any other method.
I think to avoid this I would need to change the <trans-attribute> tag in ejb-jar.xml
from "Required" to "Never" for each method. Even after doing that, I get the same
effect.
My whole idea is to run each entity bean method outside a transaction context.
Can anyone please suggest me a way to do that .
Thanks in advance.

Deyan,
I used to think that having Required on Entity is mandatory.
Anyway, it would be interesting to hear the author.
Regards,
Slava Imeshev
"Deyan D. Bektchiev" <[email protected]> wrote in message news:[email protected]...
Hi Slava,
If the EJB has in "Exclusive" concurrency no one will be able to access
the instance anyway until the local transaction completes.
If the original post meant that the data was locked then either
suspending the local transaction or using a plain DataSource would solve
the data availability as it will only be locked by the DB until the JDBC
transaction completes which might be the same duration as the EJB
transaction (but just coordinated by the calling code) and then it would
be just coding overhead to get rid of the EJB transaction in the first
place.
Personally I prefer making all Entity EJBs "Required" and where I really
need separate transaction set to "RequiresNew". For Session EJBs it's a
different story and there "NotSupported" makes sense sometimes (we have
some session EJBs that can execute for 30 minutes or more and locking
too many resources for that long really takes the scalability away).
So the answer to the original issue might be to just set the concurrency
to "Database" or "Optimistic" and do findByPK from all of the other
threads that need to do the EJB access.
Plus the benefit of using "Required" with Weblogic is that should you
ever reenter (or access multiple times) your EJB you get the same
instance if you are running inside a transaction and the instance was
already part of it -- thus reducing stale data access.
Regards,
Dejan
Slava Imeshev wrote:
Hi Deyan,
That's all correct. Myself I'm wondering what "usability by any other method"
means in the original post. Knowing that we should be able to give a right
answer:
"As a result each method locks the entity bean there by making it unusable
by any other method"
Regards,
Slava Imeshev
"Deyan D. Bektchiev" <[email protected]> wrote in message news:[email protected]...
Well,
For Weblogic you still get a "local" transaction for the duration of the
EJB call whether you want it or not (if necessary it suspends any
current transaction before the call and start the "local" one).
You can play with the TransactionManager or the Weblogic TxHelper class
to suspend that transaction and then resume it at the end of the call
but if you are doing CMP then it could lead to data corruption.
A much cleaner way of doing this is to use a plain DataSource and not a
TXDataSource that doesn't care about any transaction already in progress
and the connections that you get from it are not transaction aware.
HTH,
Dejan
Mark Shaffer wrote:
I don't think I believe you, because the "Never" transaction attribute means that
not only will the container not create a transaction to invoke the method, it
will actually throw an exception if an attempt is made to invoke the method from
a thread with an existing transaction context.
Anyway. the "NotSupported" transaction attribute will cause the container to call
the method outside of any transaction context. If the calling thread has no existing
transaction then a new one will not be created, and if the calling thread has
an existing transaction then that transaction will be suspended while the method
is called.
Hope this helps...
Mark
"K W" <[email protected]> wrote:
Presently all methods of an entity bean run in a transaction. As a result
each
method locks the entity bean there by making it unusable by any other
method.
I think to avoid this I would need to change the <trans-attribute> tag
in ejb-jar.xml
from "Required" to "Never" for each method. Even after doing that, I
get the same
effect.
My whole idea is to run each entity bean method outside a transaction
context.
Can anyone please suggest me a way to do that .
Thanks in advance.

MDB container transaction

Similar Messages

Maybe you are looking for