MDB Transaction Management Problem

Hi,
I am implementing a container managed MDB. The process involves implementing the retry queue and a dead letter queue in case the message is not processed properly.
In one of the scenarios, an exception gets thrown during the message processing and the message is sent to the retry queue. But somehow it is not being delivered to this queue also and an exception gets thrown. I can see the stacktrace in the logs but somehow This exception is not causing my transaction to rollback in the original MDB and hence the message is getting lost.
I am using WSAD 5.1 with websphere app server.
Can someone help please.

Hi,
          Thanks for your reply.
          Unfortunatelly, I didn't find any information about that issue in Release Notes of Service Pack 5.
          Could you show me any source of information about this problem as it is known issue ?

Similar Messages

Ejb transaction management jndi lookup name problem

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

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

The MSDTC transaction manager failing : It was unable to pull the transaction from the source transaction manager due to communication problems

Microsoft Tech Gurus,
Can you please assist on this issue. ? There are 3 different errors stacks for this issue - Our Application is not connecting with MS SQL Server. Everything was fine until Monday. There are changes have done on those Apps and DB servers.
Please refer the attached document - which has all the errors with details. Appreciate all your support.!
Error 1 :
TISAppenderLog4net.Log4NetException: The underlying provider failed on Open. ---> System.Data.EntityException: The underlying provider failed on Open. ---> System.Transactions.TransactionManagerCommunicationException:
Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException: The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems. Possible
causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception
from HRESULT: 0x8004D02B)
Error 2 :
TISAppenderLog4net.Log4NetException: Installation of the application [TestApp] failed ---> TiS.Core.TisCommon.TisException: Installation of the application [TestApp] failed
Error 3 :
TISAppenderLog4net.Log4NetException: Cannot open database "TestApp_Workflow" requested by the login. The login failed.
Login failed for user 'eflow_user'. ---> System.Data.SqlClient.SqlException: Cannot open database "TestApp_Workflow" requested by the login. The login failed.
Login failed for user 'eflow_user' at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1
wrapCloseInAction)

Error 1:-
http://blogashwani.blogspot.in/2013/05/dtc-issue-can-not-find-each-other-by.html
It seemed like a case when (sometimes) machines were not able to locate each other.
The solution was simple (as suggested on forums available on the internet)- make identification easier :).
Either access the machines using IP instead of their names or make a mapping entry in the "hosts" file located at "C:\windows\system32\drivers\etc".
We took the "hosts" file approach and there were no errors once we made the changes.
Error 3 :
Try login from mssql using that account check it verifed
Distributed Transaction Coordinator restart and check.

Transactional Messaging Problem

Hi,
The problem I am facing is, I have multiple publishers that can send the same type of messages to the topics and mutiple subscribers are receiving the messages (many-to-many). Suppose the publisher makes changes to a database row, and then send a message to the topic reflecting that change. At the same time, another publisher makes changes to the same database row and then send a message to the topic. If there is no transaction involved on the publisher side, it is possible that the second publisher's message arrives at subscriber side first. This could potentially cause trouble on the subscriber side. How can I guarantee the order of the messages published into the topic? In a situation where message service is down and my publisher has the ability to resend the message after service is back alive, the message it is sending will obviously out of order. So what is the best approach to this kind of problem? How can I ensure the right order delivered to the other end of message pipe? Thanks.

Hi,
You are right by saying that updating your database and publishing your messages within the scope of a transaction will solve your problem. But however, you need to use the right database transactional model. The best one to go for is the strict serialisation model that will guarantee you that write operations are strictly done sequentially and then that your messages are published in the right order. Note that this model has a certain degree of overhead that you may be able to relax so that to improve performance.
On the messaging side you will need to use a XA compliant JMS provider as well as a transaction manager. You can achieve that by using an app server or you can use a MDS (message driven service) container. For example, Arjuna provides such a container (http://www.arjuna.com/products/arjunams/tutorials/mds/index.html) that is roughly speaking a light weight MDB container that provides you with concurrent message processing as well as container managed transactions. The MDS container comes with a full JTA compliant transaction manager.
Note that in the event of a database or a JMS bus failure you will rollback your transaction and take the necessary action that could simply be re-trying later or waiting for the faulty resource to reboot.
Hope this helps,
Arnaud
www.arjuna.com

MDB Transaction

Hi,
I'm having some issues in same cases with MDB transactions on WL. I have an MDB deployed on a 9.2 WL defined as a CMP with auto-acknowledge in the EJB descriptor (using EJB 2.1 standards) which listens on a queue which is defined in the local WL JMS module and mapped to an external Tibco EMS queue.
Used descriptor configuration :
<messaging-type>javax.jms.MessageListener</messaging-type>
<transaction-type>Container</transaction-type>
<message-destination-type>javax.jms.Queue</message-destination-type>
<activation-config>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Queue</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>acknowledgeMode</activation-config-property-name>
<activation-config-property-value>Auto-acknowledge</activation-config-property-value>
</activation-config-property>
</activation-config>
The MDB processes the message, accesses a DB and sends it of the an external system. When no exception happened the MDB method finishes and normally the container acknowledges
This all works great untill we put some load on the queue. Sometimes we note that a JMS message gets stuck in the input queue when lots of messages are being put on the input queue. We can trace that such messages actually were picked up by the MDB and processed to a certain extend.
Sometimes the processing log trace just stops in the middle of processing. Sometimes the entire processing log trace is present. However the JMS messages are kept in the input queue and seem to locked (they can't be flushed out as long as the component is still running).
It looks like the messages are awaiting acknowledgement from the WL container manager but somehow the transaction got lost and never got back to the external EMS to acknowledge the message in the input queue.
I was wondering if there is a way to monitor CMP transactions or the status of the container manager? As far as I know the container manager always tries to contact the remote EMS server to acknowledge the message in this setup. What would happen if the remote EMS server would be overloaded and could not respond back to the WL container manager to confirm message acknowledgment?

Thanks for the reply. There are no errors what so ever regarding MDB issues. Not in the weblogic / console logging, nor in the logging of the component itself.
The MDB itself is setup to have 16 concurrent beans per component deployment. The component is clustered over 4 server instances. So there are quite some concurrent MDBs running. However since the messages get stuck for weeks eventhough the component only has bursts of messages to process, one would think that the the stuck messages would be processed whenever the component has some spare time (which it has a lot between the bursts).
Therefor i doubt it has anything to do with too little MDBs running. But frankly I have no idea what's wrong.

Configuration for Transaction Management

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


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

Transaction Management

Hi there,
I have a number of table manager classes, each of which saves data to
their respective table in the database. With these tables it is likely
that they may be locked by other users on occasion so I have put in
exception handlers on the managers to cater for this. The user has the
option to keep trying or give up and try again later.
Now sometimes three or more tables may need to be updated together and if
one fails to commit then no data for the three tables should be saved to
the database. In such a case the 'save' method of the three or more table
managers are called from a single method within one 'dependent' forte
transaction. Before calling the save methods, I call another method which
starts a SQL 'read write wait 10' transaction reserving each table needed
within the transaction.
I have read through the Transactions chapter of the Forte Accessing
Databases manual and see examples where a number of SQL statements are
included within a transaction and each one commits only if all are
successful at the end of the transaction. I assumed my approach would be
similar especially when using the 'begin dependent transaction' statement.
But if the application gets around to saving the second table which is
locked and the user decides not to commit, the first table is still updated
in the database.
Is it because my SQL statements are in seperate methods and are commited
when the method is complete? Or am I missing something somewhere?
Any help greatly appreciated.
Thank you.
Vanessa.
===========================================< @
===========================================Vanessa Rumball
Analyst Programmer Phone: (03) 479 8285
A.T.S. Fax: (03) 479 5080
University of Otago Email: [email protected]
PO Box 56
Dunedin
New Zealand
===========================================< @
===========================================-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Hello Peter,
Well, we are using a slightly different approach. We have a SO
(we call it Persistence Manager)
and DBSession SO (user visible) in one partition. This partition
is load balanced.
All database activity is in the Persistence Manager - in one
partition that uses one DBSession. In this approach we do not
have possibility for deadlocks between different DBSessions
because for example an activity that involves several tables
will be executed within one DBSession. And since this partition
is load balanced, the access to the database will not be
blocked.
Hope this makes sense.
Best regards,
Dimitar mailto:[email protected]
Monday, May 17, 1999, 1:55:35 PM, you wrote:
PSHAMSDI> Hi,
PSHAMSDI> I would like to add to the question on the concern on sharing DBSession.
PSHAMSDI> The fact that a DBSession is shared and is blocked from other threads within
PSHAMSDI> a transaction make it a candidate for "dead-lock". That's why in my
PSHAMSDI> application, up until now, I dare not to load-balance a DBSession or involve
PSHAMSDI> multiple DBSessions in a update transaction. I have experience that when
PSHAMSDI> multiple DBSessions are involved in a update transaction, there is a great
PSHAMSDI> choice that the DBSessions are dead-locked by different threads.
PSHAMSDI> The way that we do it now is very dumb and hard to maintain. We pass the
PSHAMSDI> DBSession along for all the calls involved in a update transaction.
PSHAMSDI> However, if someone forget to follow the convention, the application will
PSHAMSDI> get dead-locked and I have to use dumb status on the partitions to trace
PSHAMSDI> back the invoking method. It is horrible and with no guarentee to find the
PSHAMSDI> source of the problem.
PSHAMSDI> I have figured a more extensive architecture to solve this problem. But
PSHAMSDI> before I fully implement my design, I would like to know if there is already
PSHAMSDI> a elegant solution out there.
PSHAMSDI> Thanks for any help in advance.
PSHAMSDI> Best regards,
PSHAMSDI> Peter Sham.
PSHAMSDI> -----Original Message-----
PSHAMSDI> From: Dimitar Gospodinov [SMTP:[email protected]]
PSHAMSDI> Sent: Monday, May 17, 1999 2:47 PM
PSHAMSDI> To: Vanessa Rumball
PSHAMSDI> Cc: [email protected]
PSHAMSDI> Subject: Re: Transaction Management
PSHAMSDI> Hello Vanessa,
PSHAMSDI> You should use dependent transactions - the "begin
PSHAMSDI> transaction"
PSHAMSDI> statement is equal to "begin dependent transaction" statement.
PSHAMSDI> So you can have several methods for saving the data in
PSHAMSDI> different
PSHAMSDI> tables - all these method contain "begin transaction .. end
PSHAMSDI> transaction" construction.
PSHAMSDI> Then you can have one "wrapper" method that calls the above
PSHAMSDI> methods. This method also contains "begin transaction .. end
PSHAMSDI> transaction" construction.
PSHAMSDI> Now you have dependent transactions - if some of the
PSHAMSDI> transaction
PSHAMSDI> fails , the whole bunch of transaction will fail.
PSHAMSDI> If you want to catch the Deadlocks you may register for the
PSHAMSDI> AbortException exception and re-try your outermost
PSHAMSDI> transaction.
PSHAMSDI> Hope this helps.
PSHAMSDI> Best regards,
PSHAMSDI> Dimitar mailto:[email protected]
PSHAMSDI> Monday, May 17, 1999, 6:08:17 AM, you wrote:
PSHAMSDI> VR> Hi there,
PSHAMSDI> VR> I have a number of table manager classes, each of which saves
PSHAMSDI> data to
PSHAMSDI> VR> their respective table in the database. With these tables it is
PSHAMSDI> likely
PSHAMSDI> VR> that they may be locked by other users on occasion so I have put
PSHAMSDI> in
PSHAMSDI> VR> exception handlers on the managers to cater for this. The user
PSHAMSDI> has the
PSHAMSDI> VR> option to keep trying or give up and try again later.
PSHAMSDI> VR> Now sometimes three or more tables may need to be updated
PSHAMSDI> together and if
PSHAMSDI> VR> one fails to commit then no data for the three tables should be
PSHAMSDI> saved to
PSHAMSDI> VR> the database. In such a case the 'save' method of the three or
PSHAMSDI> more table
PSHAMSDI> VR> managers are called from a single method within one 'dependent'
PSHAMSDI> forte
PSHAMSDI> VR> transaction. Before calling the save methods, I call another
PSHAMSDI> method which
PSHAMSDI> VR> starts a SQL 'read write wait 10' transaction reserving each
PSHAMSDI> table needed
PSHAMSDI> VR> within the transaction.
PSHAMSDI> VR> I have read through the Transactions chapter of the Forte
PSHAMSDI> Accessing
PSHAMSDI> VR> Databases manual and see examples where a number of SQL
PSHAMSDI> statements are
PSHAMSDI> VR> included within a transaction and each one commits only if all
PSHAMSDI> are
PSHAMSDI> VR> successful at the end of the transaction. I assumed my approach
PSHAMSDI> would be
PSHAMSDI> VR> similar especially when using the 'begin dependent transaction'
PSHAMSDI> statement.
PSHAMSDI> VR> But if the application gets around to saving the second table
PSHAMSDI> which is
PSHAMSDI> VR> locked and the user decides not to commit, the first table is
PSHAMSDI> still updated
PSHAMSDI> VR> in the database.
PSHAMSDI> VR> Is it because my SQL statements are in seperate methods and
PSHAMSDI> are commited
PSHAMSDI> VR> when the method is complete? Or am I missing something
PSHAMSDI> somewhere?
PSHAMSDI> VR> Any help greatly appreciated.
PSHAMSDI> VR> Thank you.
PSHAMSDI> VR> Vanessa.
PSHAMSDI> VR> ===========================================< @
PSHAMSDI> >>===========================================
PSHAMSDI> VR> Vanessa Rumball
PSHAMSDI> VR> Analyst Programmer Phone: (03) 479 8285
PSHAMSDI> VR> A.T.S. Fax: (03) 479 5080
PSHAMSDI> VR> University of Otago Email:
PSHAMSDI> [email protected]
PSHAMSDI> VR> PO Box 56
PSHAMSDI> VR> Dunedin
PSHAMSDI> VR> New Zealand
PSHAMSDI> VR> ===========================================< @
PSHAMSDI> >>===========================================
PSHAMSDI> VR> -
PSHAMSDI> VR> To unsubscribe, email '[email protected]' with
PSHAMSDI> VR> 'unsubscribe forte-users' as the body of the message.
PSHAMSDI> VR> Searchable thread archive
PSHAMSDI> <URL:http://pinehurst.sageit.com/listarchive/>
PSHAMSDI> -
PSHAMSDI> To unsubscribe, email '[email protected]' with
PSHAMSDI> 'unsubscribe forte-users' as the body of the message.
PSHAMSDI> Searchable thread archive
PSHAMSDI> <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Distributed transactions/jdbc problem WL60

Hi
          Our company has aworking application running on WLS5.1sp9.
          Im in the process of migrating it to WL6.0sp2.
          Our domain has 2 clusters each running 2 servers:
          1) servlet engines (handling http requests from clients, running servlets
          and jsp's)
          2) ejb containers (runnigour entities and session beans, working with Oracle
          8i database using connection pool and TxDataSource)
          The scenario:
          - a client request invokes a servlet on one of the servlet engines.
          - the servlet opens a jndi context to one of the ejb containers
          - the servlet open a transaction on a UserTransaction stub on that ejb.
          - then the servlet calls an entity bean using a home interface looked up
          using the same context.
          - the entity bean uses DataSource lookup in its own servers jndi to rerieve
          a connection.
          and then i get the following exception:
          java.sql.SQLException: No default driver for database type:
          jdbc:weblogic:jts
          at
          weblogic.jdbcbase.t3.Driver.seeIfWeNeedToInferDriverNameAndUrlFrom(Driver.ja
          va:456)
          at weblogic.jdbcbase.t3.Driver.getAllPropsFrom(Driver.java:255)
          at weblogic.jdbcbase.t3.Driver.connect(Driver.java:75)
          at weblogic.jdbcbase.jts.Driver.createRemoteConnection(Driver.java:199)
          at weblogic.jdbcbase.jts.Driver.connect(Driver.java:134)
          at
          weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java
          :44)
          at com.unisfair.util.DBHelper.getConnection(DBHelper.java:43)
          the transaction toString() gives:
          transaction=(IdHash=7541556,Name = [EJB
          UserBeanImpl.generateSessionSuffix()],Xid=2:b53da78d3c1badbb,Status=Active,n
          umRepliesOwedMe=0,numRepliesOwedOthers=1,seconds since begin=0,seconds
          left=30,activeThread=Thread[ExecuteThread: '8' for queue: 'default',5,Thread
          Group for Queue:
          'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=new,assig
          ned=none),SCInfo[ejb2]=(state=active),SCInfo[servlet2]=(state=active),SCInfo
          [ejb1]=(state=active),properties=({weblogic.transaction.name=[EJB
          UserBeanImpl.generateSessionSuffix()], weblogic.jdbc=t3://10.0.0.31:7007}))
          However the error happens on the other ejb server 10.0.0.33:7007
          It seems that the jts driver tries to get a remote connection on the server
          that coordinates the transaction but uses the deprecated t3 driver.
          I hope someone can help us since this problem is a good enough reason for us
          not moving on to WL6.0 we also looked at WL6.1 Beta and theres nothing new
          about it either.
          thanks
          Dror Last
          Senior Software Engineer
          Unisfair Inc.
          12 Yad Haruzim St. Tel Aviv 67778 Israel
          Tel: +972-3-5373738 Ext. 243
          Fax: +972-3-5373731
          GSM: +972-55-723710
          mailto:[email protected]
          http://www.unisfair.com/


<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by JDBC_TX ():
In the readme file of Oracle JDBC drivers 8.1.6.0.1 (http://technet.oracle.com/software/tech/java/sqlj_jdbc/files/Readme_01.txt)
it mentioned that it supports "distributed transactions".
As I understand, JDBC transaction is connection based and uses Oracle internal transaction manager. In order to do "distributed transactions", I must have at least two connections open at the same time each to its own database instance. How does the two connections coordinate the transactions? I thought in order to support "distributed transactions", one has to build a higher layer to encapsulate the two connections and therefore coordinate the distributed transactions. Any examples will be welcome.<HR></BLOCKQUOTE>
The two branches of the transaction are coordinated using 2-phase commit.
For samples look under
$ORACLE_HOME/jdbc/demo/samples/oci8/jdbc20-samples/
null

Database transaction management in Web services

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

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

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

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

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

RE: Re[2]: Transaction Management

Hi,
Thanks for the reply. But my situation may require more than 1 DBSession
per Persistence Manager, as under the same Domain problem, my persistent
objects spread across multiple databases ( due to some legacy and package
systems ).
On the other hand, I think your model would be helpful in some cases.
Following is what I think you are doing in your model in order to make use
of this Persistence Manager.
1. Client program would retrieve business object from this persistence
manager;
2. When persistence manager return the requested object, it would save
its pointer to the business object.
3. When client call save()/delete() on the business object, it would
then route the request to the persistence manager by its pointer.
Please correct me if I'm wrong.
As mentioned, I have another design on this issue. When my document is
ready, would you like to take a look. I just want to invite more opinion on
this "Framework" with which I've spent at least half a year to work on.
Best regards,
Peter Sham.
-----Original Message-----
From: Dimitar Gospodinov [SMTP:[email protected]]
Sent: Monday, May 17, 1999 5:41 PM
To: Peter Sham (HTHK - Assistant Manager - Software Development,
IITB)
Cc: Vanessa Rumball; [email protected]
Subject: Re[2]: Transaction Management
Hello Peter,
Well, we are using a slightly different approach. We have a SO
(we call it Persistence Manager)
and DBSession SO (user visible) in one partition. This
partition
is load balanced.
All database activity is in the Persistence Manager - in one
partition that uses one DBSession. In this approach we do not
have possibility for deadlocks between different DBSessions
because for example an activity that involves several tables
will be executed within one DBSession. And since this
partition
is load balanced, the access to the database will not be
blocked.
Hope this makes sense.
Best regards,
Dimitar mailto:[email protected]
Monday, May 17, 1999, 1:55:35 PM, you wrote:
PSHAMSDI> Hi,
PSHAMSDI> I would like to add to the question on the concern on
sharing DBSession.
PSHAMSDI> The fact that a DBSession is shared and is blocked from
other threads within
PSHAMSDI> a transaction make it a candidate for "dead-lock". That's
why in my
PSHAMSDI> application, up until now, I dare not to load-balance a
DBSession or involve
PSHAMSDI> multiple DBSessions in a update transaction. I have
experience that when
PSHAMSDI> multiple DBSessions are involved in a update transaction,
there is a great
PSHAMSDI> choice that the DBSessions are dead-locked by different
threads.
PSHAMSDI> The way that we do it now is very dumb and hard to
maintain. We pass the
PSHAMSDI> DBSession along for all the calls involved in a update
transaction.
PSHAMSDI> However, if someone forget to follow the convention, the
application will
PSHAMSDI> get dead-locked and I have to use dumb status on the
partitions to trace
PSHAMSDI> back the invoking method. It is horrible and with no
guarentee to find the
PSHAMSDI> source of the problem.
PSHAMSDI> I have figured a more extensive architecture to solve this
problem. But
PSHAMSDI> before I fully implement my design, I would like to know
if there is already
PSHAMSDI> a elegant solution out there.
PSHAMSDI> Thanks for any help in advance.
PSHAMSDI> Best regards,
PSHAMSDI> Peter Sham.
PSHAMSDI> -----Original Message-----
PSHAMSDI> From: Dimitar Gospodinov [SMTP:[email protected]]
PSHAMSDI> Sent: Monday, May 17, 1999 2:47 PM
PSHAMSDI> To: Vanessa Rumball
PSHAMSDI> Cc: [email protected]
PSHAMSDI> Subject: Re: Transaction Management
PSHAMSDI> Hello Vanessa,
PSHAMSDI> You should use dependent transactions - the
"begin
PSHAMSDI> transaction"
PSHAMSDI> statement is equal to "begin dependent
transaction" statement.
PSHAMSDI> So you can have several methods for saving
the data in
PSHAMSDI> different
PSHAMSDI> tables - all these method contain "begin
transaction .. end
PSHAMSDI> transaction" construction.
PSHAMSDI> Then you can have one "wrapper" method that
calls the above
PSHAMSDI> methods. This method also contains "begin
transaction .. end
PSHAMSDI> transaction" construction.
PSHAMSDI> Now you have dependent transactions - if
some of the
PSHAMSDI> transaction
PSHAMSDI> fails , the whole bunch of transaction will
fail.
PSHAMSDI> If you want to catch the Deadlocks you may
register for the
PSHAMSDI> AbortException exception and re-try your
outermost
PSHAMSDI> transaction.
PSHAMSDI> Hope this helps.
PSHAMSDI> Best regards,
PSHAMSDI> Dimitar
mailto:[email protected]
PSHAMSDI> Monday, May 17, 1999, 6:08:17 AM, you wrote:
PSHAMSDI> VR> Hi there,
PSHAMSDI> VR> I have a number of table manager classes,
each of which saves
PSHAMSDI> data to
PSHAMSDI> VR> their respective table in the database. With
these tables it is
PSHAMSDI> likely
PSHAMSDI> VR> that they may be locked by other users on
occasion so I have put
PSHAMSDI> in
PSHAMSDI> VR> exception handlers on the managers to cater
for this. The user
PSHAMSDI> has the
PSHAMSDI> VR> option to keep trying or give up and try again
later.
PSHAMSDI> VR> Now sometimes three or more tables may need
to be updated
PSHAMSDI> together and if
PSHAMSDI> VR> one fails to commit then no data for the three
tables should be
PSHAMSDI> saved to
PSHAMSDI> VR> the database. In such a case the 'save'
method of the three or
PSHAMSDI> more table
PSHAMSDI> VR> managers are called from a single method
within one 'dependent'
PSHAMSDI> forte
PSHAMSDI> VR> transaction. Before calling the save methods,
I call another
PSHAMSDI> method which
PSHAMSDI> VR> starts a SQL 'read write wait 10' transaction
reserving each
PSHAMSDI> table needed
PSHAMSDI> VR> within the transaction.
PSHAMSDI> VR> I have read through the Transactions chapter
of the Forte
PSHAMSDI> Accessing
PSHAMSDI> VR> Databases manual and see examples where a
number of SQL
PSHAMSDI> statements are
PSHAMSDI> VR> included within a transaction and each one
commits only if all
PSHAMSDI> are
PSHAMSDI> VR> successful at the end of the transaction. I
assumed my approach
PSHAMSDI> would be
PSHAMSDI> VR> similar especially when using the 'begin
dependent transaction'
PSHAMSDI> statement.
PSHAMSDI> VR> But if the application gets around to saving
the second table
PSHAMSDI> which is
PSHAMSDI> VR> locked and the user decides not to commit, the
first table is
PSHAMSDI> still updated
PSHAMSDI> VR> in the database.
PSHAMSDI> VR> Is it because my SQL statements are in
seperate methods and
PSHAMSDI> are commited
PSHAMSDI> VR> when the method is complete? Or am I missing
something
PSHAMSDI> somewhere?
PSHAMSDI> VR> Any help greatly appreciated.
PSHAMSDI> VR> Thank you.
PSHAMSDI> VR> Vanessa.
PSHAMSDI> VR> ===========================================< @
PSHAMSDI> >>===========================================
PSHAMSDI> VR> Vanessa Rumball
PSHAMSDI> VR> Analyst Programmer Phone:
(03) 479 8285
PSHAMSDI> VR> A.T.S. Fax:
(03) 479 5080
PSHAMSDI> VR> University of Otago Email:
PSHAMSDI> [email protected]
PSHAMSDI> VR> PO Box 56
PSHAMSDI> VR> Dunedin
PSHAMSDI> VR> New Zealand
PSHAMSDI> VR> ===========================================< @
PSHAMSDI> >>===========================================
PSHAMSDI> VR> -
PSHAMSDI> VR> To unsubscribe, email '[email protected]'
with
PSHAMSDI> VR> 'unsubscribe forte-users' as the body of the
message.
PSHAMSDI> VR> Searchable thread archive
PSHAMSDI> <URL:http://pinehurst.sageit.com/listarchive/>
PSHAMSDI> -
PSHAMSDI> To unsubscribe, email '[email protected]' with
PSHAMSDI> 'unsubscribe forte-users' as the body of the
message.
PSHAMSDI> Searchable thread archive
PSHAMSDI> <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Hi Bolun,
If you have 2 different UOM(KG and PC) you can see 2 sub-totals only. If you have more, you will see more...
You can try this: Some work around's ........
Option1: Convert other Units of measures into KG's or PC's or
Option2: Add one more Indicator at infoprovider level and populate indicator accordingly., based on UOM and use in report. or
Option3: Make UOM as User Input and restrict report based on that...
Hope it Helps
Srini

Does transaction manager also releases the connections ?

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

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

ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 237

Hello,
I encountered ORA-10561 while I was recovering my DB.
Problem Background :-
I took a hotbakup of my DB running in Windows, I edited the Pfile and recreated the control file
I was able to succesfully mount the DB
The I gave the below command to apply the redologs and recover the DB
And the errors followed as mentioned.
The HOTBACKUP was copied and restored using a USB-PENdrive. I suspect that the datafiles and / or ARCHIVE LOGS would have had some format issues due to O/S {WINXP ---> RHEL5}
If this is the case ? then I would like to know how to convert the format of the files(Datafiles and or Redologs)
into acceptable format
>
SQL> recover database until time '2010-03-15:18:08:05' using backup controlfile;
ORA-00279: change 3447582 generated at 03/15/2010 17:41:42 needed for thread 1
ORA-00289: suggestion : /home/oracle/NEW/ARCHIVE/ARC0000000144_0706577643.0001
ORA-00280: change 3447582 for thread 1 is in sequence #144
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/home/oracle/NEW/ARCHIVE/ARC00144_0706577643.001
ORA-00283: recovery session canceled due to errors
ORA-10562: Error occurred while applying redo to data block (file# 1, block#
1658)
ORA-10564: tablespace SYSTEM
ORA-01110: data file 1: '/home/oracle/NEW/oradata/O1_MF_SYSTEM_5M9ZKSSW_.DBF'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 237
ORA-00600: internal error code, arguments: [4502], [0], [], [], [], [], [], []
>
Thanks in advance.
Regards,
Valli

You need to give much more information:
What version of Oracle? 10gR2 is not a version, 10.2.0.1 is a version.
What version of Windows, exactly? What version of linux?
ORA-600 means you need to talk to Oracle support. There is an ora-600 lookup tool, which basically searches the knowledge base (for ora-600[4502] in your case, which brings up a bunch of really, really, really old docs).
How exactly did you take the "hot backup?" There are a number of ways to do things with that name, some of which are just plain wrong.
How exactly did you get the backup from one machine to another? Which exact commands did you use to copy the files to the usb and from the usb? Did you do it more than once?
Why are you using the backup controlfile syntax? There are valid reasons, and invalid reasons to do that.
What exactly did you change in the pfile?
What does the alert log say about all this?

Customizing Transaction Manager

Hi everybody,
I'd like to know if there is some documentation for customizing CFM module (more precisely for Transaction Manager functionalities. It seemes to me that exists a document named FSCDE1)
thanks in advance,
Mirco

Hi...
The following link may be of use to you. This document is Basic Functions in Treasury Management. It has covered transaction and position management. You have to get registered with the site which is free.
http://sapinformation.com/Documents/SAPTrainingCourses/AC810-BasicFunctionsInTreasuryManagement.doc
If you find any problem simply register with www.sapsuperusers.com and check out in access training material section.
Assign points if useful
Regards
Aravind

6.1 XA manager problem

Hi,
          We am using Weblogic 6.1 with no service packs running on Windows NT
          with a Oracle 8i database backend. We seem to be having some problems
          with our transaction manager. Every now and then (not sure what
          instigates it) we get a period of time where we can not get a database
          connection from our tx datasource. We are not hitting the limit on the
          number of connections. The following message always appears in the
          server log before this occurs:
          Dec 4, 2001 3:13:32 PM GMT TW01D21 Warning
          JTA XA resource [weblogic.jdbc.jts.Connection] has not
          responded in the last 120 second(s).
          The following message also appears in the log before the situation
          resolves itself:
          Dec 4, 2001 3:31:47 PM GMT TW01D21 Info
          JTA Previously unavailable XA resource
          [weblogic.jdbc.jts.Connection] is now available.
          We think that be remotely refreshing the connection pool using the
          command line utility we can make the second message appear but this may
          jsut be coincidence. This situation seem to coincide with legitimate
          transaction timeouts whereby queries take too long to complete (more
          than 60 seconds). We have thoroughly tested the application in
          situations where transaction timeouts occur and never noticed any
          problems with the connection pool or data source until just recently.
          Does anyone know what could cause this behavior how we could develop a
          work around?
          Thanks,
          Steve


It could possibly be caused by blocking JDBC calls, which are called by the
          JTS driver's XAResource wrapper. Try taking thread dumps when you see the
          resource unavailable error to see what the blocking threads are doing, if
          any.
          It is true that turning off the resource health monitoring won't solve the
          problem. For JTS driver, we found that unresponsive XAResource calls are
          often caused by blocking JDBC calls for some transactions/connections,
          rather than an unavailable database. Thus, we remove the checks to be more
          permissive to allow other transactions/connections to proceed even if one
          gets stuck. The downside is that the resource health monitoring safeguard
          is not exercised for JTS driver if the database is really unavailable.
          Contact BEA Support at [email protected] for further assistance.
          Regards,
          Priscilla
          Steve Snodgrass <[email protected]> wrote in message
          news:[email protected]...
          > Thanks for the response. I guess my question now is this. What could cause
          my
          > XAResource to become unresponsive? I am trying to reproduce this problem
          but
          > thus far have been unable to do so in a test environment. It unfortunely
          only
          > occurs in our production release.
          >
          > Also, from what you are saying, it sounds like upgrading to sp1 will solve
          our
          > problem by not locking the XAResource but doesn't this mask the deeper
          problem
          > which is causing the unresponsivness?
          >
          >
          > Thanks,
          > Steve
          >
          >
          >
          > Priscilla Fung wrote:
          >
          > > This is due to JTS driver's XAResource calls being unresponsive for more
          > > than 2 minutes. Once a XAResource does not respond for more than 2
          minutes,
          > > JTA declares the resource dead and shuns further calls to it to prevent
          > > potential loss of server threads to dead resources.
          > >
          > > When a new JTS connection is obtained later and its new XAResource is
          > > enlisted with JTA, the new XAResource is re-registered with JTA and thus
          the
          > > JTS driver is declared available again. If not, unavailable resource
          will
          > > be declared available by JTA again after 30 mins.
          > >
          > > For 6.1 SP1 onwards, resource health monitoring is turned off for JTS
          > > driver.
          > >
          > > Regards,
          > > Priscilla
          > >
          > > Steve Snodgrass <[email protected]> wrote in message
          > > news:[email protected]...
          > > > Hi,
          > > > We am using Weblogic 6.1 with no service packs running on Windows NT
          > > > with a Oracle 8i database backend. We seem to be having some problems
          > > > with our transaction manager. Every now and then (not sure what
          > > > instigates it) we get a period of time where we can not get a database
          > > > connection from our tx datasource. We are not hitting the limit on the
          > > > number of connections. The following message always appears in the
          > > > server log before this occurs:
          > > >
          > > > Dec 4, 2001 3:13:32 PM GMT TW01D21 Warning
          > > > JTA XA resource [weblogic.jdbc.jts.Connection] has not
          > > > responded in the last 120 second(s).
          > > >
          > > > The following message also appears in the log before the situation
          > > > resolves itself:
          > > >
          > > > Dec 4, 2001 3:31:47 PM GMT TW01D21 Info
          > > > JTA Previously unavailable XA resource
          > > > [weblogic.jdbc.jts.Connection] is now available.
          > > >
          > > > We think that be remotely refreshing the connection pool using the
          > > > command line utility we can make the second message appear but this
          may
          > > > jsut be coincidence. This situation seem to coincide with legitimate
          > > > transaction timeouts whereby queries take too long to complete (more
          > > > than 60 seconds). We have thoroughly tested the application in
          > > > situations where transaction timeouts occur and never noticed any
          > > > problems with the connection pool or data source until just recently.
          > > >
          > > > Does anyone know what could cause this behavior how we could develop a
          > > > work around?
          > > > Thanks,
          > > > Steve
          > > >
          > > >
          > > >
          > > >
          >

MDB Transaction Management Problem

Similar Messages

Maybe you are looking for