Distributed transaction (JDBC+JMS), durable MDB, NullPointException in weblogic

I am cross posting to transaction & jms, sorry if this is a mistake...
 We have a setup where JMS messages are published to a topic. The posting is transacted
 (XA) and is a consequence of a CMP update so JMS and JDBC (Oracle OCI) cooperate
 to commit, or not.
 Most of the time, transactions issue just a few JMS messages but at least once
 a day, we issue hundred of thousands of such messages (max has been about 600000
 but typically 300000).
 Our setup is four instances of Weblogic 6.1SP3 (two clustered, two not), the topic
 is on one of them (all 3 other servers connect to that instance to publish) and
 we have a couple MDBs deployed only on the instance that has the JMSServer and
 they all listen to the local topic. The transactionnal settings of these MDBs
 is CMT and XA (because the beans will write to the DB). Furthermore, these MDB
 have been setup to be durable. One of these is just a logger MDB with 20 instances
 max.
 It worked fine for a couple weeks but we have been running into problems for the
 past two days. All of a sudden, the server no longer responds to weblogic.ADMIN
 PING. The server log indicates the following error repetitively (MB of logs just
 of this)
 ####<13 nov. 03 23:15:41 CET> <Alert> <JMS> <XXXXXXX> <send1> <ExecuteThread:
 '32' for queue: 'default'> <> <> <040060> <JMSServer "OutputServerSend1", unhandled
 exception during rollback, java.lang.NullPointerException.>
 java.lang.NullPointerException
 at weblogic.jms.backend.BEDurableTopicMessageInfo.rollbackReceiveTran(BEDurableTopicMessageInfo.java:352)
 at weblogic.jms.backend.BEXATranEntrySubscribe.startRollback(BEXATranEntrySubscribe.java:145)
 at weblogic.jms.backend.BEXATranEntry.execute(BEXATranEntry.java:127)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
 The logger MDB seems to have started processing the JMS messages. This means that
 the transaction that included the JMS message publishing must have commited. Unfortunatly,
 there are only 20 log lines before the server restart, so the server must have
 hanged although it did commit the messages processed by the logger since the log
 messages are apparently not repeated. I have no idea why. I think this is coherant
 with the fact that exception above seems to relate to subscribers.
 When we restart the server, the topic gets purged and seem to be processed (we
 have not found a way to verify that each message has been processed but it's looking
 good)
 Any ideas ?
 Thanks
 Philippe

Similar Messages

Distributed transactions with container-managed MDBs

 I have built a framework that employs a high rate of code reuse while abstracting
 the complexities of inter-application communication. This allows application
 developers to focus on solving their business needs and not worry about "the plumbing"
 between the applications.
 At this point, the framework is using container-managed MDBs for Topic destinations.
 MDBs were chosen because of their concurrent nature for processing JMS messages.
 Now that I have this framework up and running, I am trying to add distributed
 transaction support and am having trouble understanding what I need to do. Here
 is how the framework works:
 The MDB will recieve a message, unmarshall it into a business object, and then
 route that object to the appropriate business class where it is then processed
 accordingly. In most cases, the processing of this message object will require
 database interaction. If any error should occur while processing the message,
 all XAResources within the transaction should rollback and ultimately, the JMS
 message will be redelivered later.
 Here is what I'm trying to find out:
 1. When control is passed to an application and it gets a DB connection, will
 that DB resource be dynamically enlisted with the transaction?
 2. Must the DB connection come from the WLS DB pool to be enlisted with the transaction?
 I ask this because the current standard at this company is to use a home-grown
 DB connection pool for getting DB connections. This is due to the fact that not
 all applications here run in a WLS environment and they wanted a standard way
 of retrieving a DB connection across applications. They also sited problems with
 WLS 4.5.1 connection pool.
 3. The documentation states that only one database may be involved in a transaction.
 If a connection to another database is required, but not needed in the current
 transaction, will WLS ignore enlisting the 2nd DB resource, or throw an exception?
 4. Where can I find detailed information about this subject? Everything
 that I have read so far has barely scratched the surface for this specific topic.
 Thanks,
 Bob.


 Hi Bob,
 If you are using WLS's XA connection pool, then the XAResource associated with
 the XA connections are enlisted with the transaction transparently for you. Enlistments
 actually occur not at getConnection, but on demand when the JDBC objects are actually
 used.
 If you are not using WLS connection pools, then you would need to enlist the XAResource
 associated with the XA connections yourself. You can obtain the transaction associated
 with the current thread by calling weblogic.transaction.TxHelper.getTransaction(),
 and then call enlistResource on the transaction.
 Weblogic has provisions that allow one (and only one) non-XA connection pool to
 participate in a distributed transaction. In this case, you will get a SQLException
 when you try to obtain a connection from a second connection pool in the same
 distributed transaction. However, if you are using real XA connection pools,
 there is no limitation and any number of XA connection pools can participate in
 the same distributed transaction.
 We will try to incorporate more info in our online docs in the future.
 -- Priscilla Fung, BEA Systems, Inc.
 "Bob Peroutka" <[email protected]> wrote:
 >
 >I have built a framework that employs a high rate of code reuse while
 >abstracting
 >the complexities of inter-application communication. This allows application
 >developers to focus on solving their business needs and not worry about
 >"the plumbing"
 >between the applications.
 >
 >At this point, the framework is using container-managed MDBs for Topic
 >destinations.
 > MDBs were chosen because of their concurrent nature for processing JMS
 >messages.
 >
 >Now that I have this framework up and running, I am trying to add distributed
 >transaction support and am having trouble understanding what I need to
 >do. Here
 >is how the framework works:
 >
 >The MDB will recieve a message, unmarshall it into a business object,
 >and then
 >route that object to the appropriate business class where it is then
 >processed
 >accordingly. In most cases, the processing of this message object will
 >require
 >database interaction. If any error should occur while processing the
 >message,
 >all XAResources within the transaction should rollback and ultimately,
 >the JMS
 >message will be redelivered later.
 >
 >Here is what I'm trying to find out:
 >
 >1. When control is passed to an application and it gets a DB connection,
 >will
 >that DB resource be dynamically enlisted with the transaction?
 >
 >2. Must the DB connection come from the WLS DB pool to be enlisted with
 >the transaction?
 >
 >I ask this because the current standard at this company is to use a home-grown
 >DB connection pool for getting DB connections. This is due to the fact
 >that not
 >all applications here run in a WLS environment and they wanted a standard
 >way
 >of retrieving a DB connection across applications. They also sited problems
 >with
 >WLS 4.5.1 connection pool.
 >
 >3. The documentation states that only one database may be involved in
 >a transaction.
 > If a connection to another database is required, but not needed in the
 >current
 >transaction, will WLS ignore enlisting the 2nd DB resource, or throw
 >an exception?
 >
 >4. Where can I find detailed information about this subject?
 > Everything
 >that I have read so far has barely scratched the surface for this specific
 >topic.
 >
 >Thanks,
 >
 >Bob.

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

Problem in Distributed transaction with Oracle 8.1.7 and Weblogic 7.0

          Hi,
          I am using two unmanaged weblogic 7.0 servers and oracle 8.1.7 enterprise edition.
          I am using oracle.jdbc.xa.client.OracleXADataSource for creating connection pool
          in weblogic. The pool gets created fine but when connection it is getting used
          it throws up following error.
          java.sql.SQLException: ORA-02044: transaction manager login denied: transaction
          in progress
          ORA-06512: at "SYS.JAVA_XA", line 0
          ORA-06512: at line 1
          at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
          at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
          at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
          at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
          at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:822)
          at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1446)
          at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1371)
          at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1900)
          at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:363)
          at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:407)
          at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:171)
          at weblogic.jdbc.jta.VendorXAResource.start(VendorXAResource.java:41)
          at weblogic.jdbc.jta.DataSource.start(DataSource.java:569)
          I don't know what is causing this problem.Please send me the pointers.
          Regards,
          Vikash


ID is a NUMBER and id.toString() is not a number, for
example it ca be a null reference.
well we tryed also this version :
ps.setLong(1, id.longValue());
moreover the exception wasn't thrown for the value of id :56 but was thrown for the value of id : 88. Hence I think it is a case of something other than my code.
michal

Does Oracle 8.1.5 with weblogic 6.1 sp2 suppports Distributed Transactions ---A really night Mare

 Which version of jdbc thin driver should i use to achieve distributed transaction
 with oracle 8.1.5 in weblogic 6.1 sp2
 right now if iam using the driver classes provided in weblogic.jar iam gettig the
 following Exception
 AccountBean.ejbCreate( id = accountId, initial balance = $ 3000.0)
 java.sql.SQLException: XA error: XAER_RMERR : A resource manager error has occured
 in the transaction branch start(
 ) failed on resource 'OracleXAPool' Unexpected error during start for XAResource
 'OracleXAPool': null
 at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1044)
 at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1010)
 at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:148)
 at weblogic.jdbc.jta.Connection.prepareStatement(Connection.java:226)
 at weblogic.jdbc.rmi.internal.ConnectionImpl.prepareStatement(ConnectionImpl.java:135)
 at weblogic.jdbc.rmi.SerialConnection.prepareStatement(SerialConnection.java:76)
 at examples.ejb.basic.beanManaged.AccountBean.ejbCreate(Unknown Source)
 at examples.ejb.basic.beanManaged.AccountBean_g1748h_Impl.ejbCreate(AccountBean_g1748h_Impl.java:172)
 at java.lang.reflect.Method.invoke(Native Method)
 at weblogic.ejb20.manager.DBManager.create(DBManager.java:492)
 at weblogic.ejb20.manager.DBManager.remoteCreate(DBManager.java:462)
 at weblogic.ejb20.internal.EntityEJBHome.create(EntityEJBHome.java:190)
 at examples.ejb.basic.beanManaged.AccountBean_g1748h_HomeImpl.create(AccountBean_g1748h_HomeImpl.java:76)
 at examples.ejb.basic.beanManaged.AccountBean_g1748h_HomeImpl_WLSkel.invoke(Unknown
 Source)
 at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:288)
 at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:93)
 at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:257)
 at weblogic.rmi.internal.BasicServerRef.dispatch(BasicServerRef.java:158)
 at weblogic.rmi.internal.ServerRequest.sendOneWayRaw(ServerRequest.java:92)
 at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:112)
 at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:253)
 at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:220)
 at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
 at $Proxy126.create(Unknown Source)
 at examples.wtc.atmi.simpapp.ToupperBean.putMessage(ToupperBean.java:194)
 at examples.wtc.atmi.simpapp.ToupperBean_8roqg7_EOImpl.putMessage(ToupperBean_8roqg7_EOImpl.java:284)
 at examples.wtc.atmi.simpapp.ToupperBean_8roqg7_EOImpl_WLSkel.invoke(Unknown
 Source)
 at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:288)
 at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:257)
 at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:22)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
 Regards
 Ranga Rao


 Oracle Server 8.1.5 does not provide support for 2PC.
 Full XA support is provided from version 8.1.7.
 Sergi
 "Lawrence" <[email protected]> wrote:
 >
 >Ranga,
 >Please use classes12.zip for this.If you still find problem, please let
 >me know.
 >Thanks
 >Lawrence
 >
 >"Ranga Rao" <[email protected]> wrote:
 >>
 >>
 >>Which version of jdbc thin driver should i use to achieve distributed transaction
 >>with oracle 8.1.5 in weblogic 6.1 sp2
 >>
 >>right now if iam using the driver classes provided in weblogic.jar iam
 >gettig
 >>the
 >>following Exception
 >>
 >>////////////////////////////////////////////////////////////////////////////////////////////
 >>AccountBean.ejbCreate( id = accountId, initial balance = $ 3000.0)
 >>java.sql.SQLException: XA error: XAER_RMERR : A resource manager error
 >has
 >>occured
 >>in the transaction branch start(
 >>) failed on resource 'OracleXAPool' Unexpected error during start for XAResource
 >>'OracleXAPool': null
 >> at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1044)
 >> at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1010)
 >> at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:148)
 >> at weblogic.jdbc.jta.Connection.prepareStatement(Connection.java:226)
 >> at weblogic.jdbc.rmi.internal.ConnectionImpl.prepareStatement(ConnectionImpl.java:135)
 >> at weblogic.jdbc.rmi.SerialConnection.prepareStatement(SerialConnection.java:76)
 >> at examples.ejb.basic.beanManaged.AccountBean.ejbCreate(Unknown
 >>Source)
 >> at examples.ejb.basic.beanManaged.AccountBean_g1748h_Impl.ejbCreate(AccountBean_g1748h_Impl.java:172)
 >> at java.lang.reflect.Method.invoke(Native Method)
 >> at weblogic.ejb20.manager.DBManager.create(DBManager.java:492)
 >> at weblogic.ejb20.manager.DBManager.remoteCreate(DBManager.java:462)
 >> at weblogic.ejb20.internal.EntityEJBHome.create(EntityEJBHome.java:190)
 >> at examples.ejb.basic.beanManaged.AccountBean_g1748h_HomeImpl.create(AccountBean_g1748h_HomeImpl.java:76)
 >> at examples.ejb.basic.beanManaged.AccountBean_g1748h_HomeImpl_WLSkel.invoke(Unknown
 >>Source)
 >> at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:288)
 >> at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:93)
 >> at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:257)
 >> at weblogic.rmi.internal.BasicServerRef.dispatch(BasicServerRef.java:158)
 >> at weblogic.rmi.internal.ServerRequest.sendOneWayRaw(ServerRequest.java:92)
 >> at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:112)
 >> at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:253)
 >> at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:220)
 >> at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
 >> at $Proxy126.create(Unknown Source)
 >> at examples.wtc.atmi.simpapp.ToupperBean.putMessage(ToupperBean.java:194)
 >> at examples.wtc.atmi.simpapp.ToupperBean_8roqg7_EOImpl.putMessage(ToupperBean_8roqg7_EOImpl.java:284)
 >> at examples.wtc.atmi.simpapp.ToupperBean_8roqg7_EOImpl_WLSkel.invoke(Unknown
 >>Source)
 >> at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:288)
 >> at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:257)
 >> at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:22)
 >> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
 >> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
 >>/////////////////////////////////////////////////////////////////////////////////
 >>
 >>Regards
 >>Ranga Rao
 >>
 >>
 >

Weblogic 5.1, Distributed Transaction and Oracle Database Link

We are planning to add a new functionality to run in Weblogic server and it
needs to update tables in two different Oracle databases. Since we are using
Weblogic 5.1 and it is unrealistic to upgrade to 6.1 in short term, we have
to deal with the fact that distributed transaction is not supported by JTS
on 5.1.
One workaround we can think of is to utilize Oracle database link. Instead
of having two connection pools, the application talks to only one database
and access the tables on the other ones through Oracle database link.
Therefore, when a session bean tries to update two tables on database 1 in
one transaction, one of the tables is just a link to the other database. We
hope that even though distributed transaction is not supported by JTS in
Weblogic 5.1, but since it is supported by Orable, it would work.
Do you think the above workaround would work? Does anyone have experience on
something like that?
Thanks in advance,
David Chen
[email protected]

Hi. You should be able to use any JDBC driver with WebLogic 5.1.
It may be the JVM that complains, if you use too old a JVM...
Joe Weinstein at BEA Systems

Distributed JDBC/JMS transaction commit order

I am using WLS 10.3.0. I have an app with container-managed EJBs which participate in distributed transactions using XA drivers for two resources, (1) a jdbc connection to Oracle database, and (2) WebLogic JMS server. In a typical EJB call, I am writing a record to the database and sending a message to a local queue which is being consumed by a MDB. My question is how can I guarantee that by the time the MDB receives the JMS message, the record will be guaranteed to have been committed in the database. It appears that occasionally the record is not yet there. Is there a way to force the jdbc commit to happen before the JMS message gets consumed? I know there is a commit_point_strength parameter that determines commit order for the database resource, but I don't see such a concept for JMS...

"The Default Time-to-Deliver attribute for XAConnectionFactory for the Weblogic JMS connection queue, is a minimum interval from when the message is SENT, to when it is available to be processed. What is really needed is a delay from COMMIT time -- not from the sent time."
<jay>
Not entirely true. Delay is not from when message is “SENT, Default Time-To-Deliver is delay at within JMS subsystem before it delivers message to consumer. It means that "Send" thread will not block for this delay and "Send" side executes no different whether there is "Time-to-Deliver" configured or not.
</jay>
"For example, imagine a distributed transaction does a JMS send, followed by a query that takes 10 seconds, followed by a commit. If Default Time-to-Deliver is set to 5 seconds, it will be completly ignored, since the 10 seconds from the send to the commit is a larger interval. So at commit it is still very possible that the MDB will receive the message before the database transaction is committed."
<jay>
This is not true also. JMS message will be available for delivery only after distributed transaction commits and more specifically "commit" part of the JMS resource completes - clock for "message delivery delay" will not start until distributed transaction is committed. Considering transaction will not commit until slow running query completes execution above scenario will not cause “Default Time-to-Deliver” workaround to fail.
Slow execution of the XA.commit() request from TM (Weblogic) to database may cause concern , however considering that TM (WebLogic) receive response of the XA.prepare() from all participating resources before XA.commit(), commit should execute with delay not more than few milliseconds and chances are negligible that proposed workaround will fail.
</jay>
"The bottom line, is that this parameter is not an effective way to control the race condition unless the JMS send is always performed as the last action in a distributed transaction.
For this reason we have gone with inserting a small configurable sleep at the start of the onMessage() methods in the MDB. Not a very elegant solution, but the one ne that works reliably."
<jay>
I think "Default Time-to-Deliver" is no less effective or no less reliable solution than placing sleep() in onMessage(), however it is more cleaner solution because it uses application server built in feature instead of updating code in onMessage().
</jay>
-jayesh@yagna

Distributed transaction just involving JMS

Hi,
          I have a MDB using a REMOTE DESTINATION to get the messages. The remote
          destination is a Topic using a Connection factory set up as following:
          User Transactions Enabled = true
          XAConnection Factory Enabled = true
          The MDB is set to type-transaction=Container and has a durable
          suscription for the Topic.
          Although, I know I´m using distributed transaction (XAConnection Factory
          Enabled = true) I am not sure if it is correct or not.
          I read that a distributed transaction is when you have 2 resources
          participating in the transaction, but, as you can see I have just JMS
          involved.
          Should I use distributed transaction or not ?
          Any comments will be appreciated!
          Thanks,
          Edith Rivera


ok Thanks for your help !
          Edith
          Peter Holditch wrote:
          > Edith,
          >
          > You should use JTA in the normal way, as you describe.
          >
          > If at commit time there is only 1 participant in the transaction (as
          > seems to ber the case in your instance) then the transaction manager
          > will optimise out the prepare phase of the processing, and you end up
          > with a single phase commit automatically.
          >
          > Regards,
          > Peter.
          >
          > Edith Rivera wrote:
          >
          >> Hi,
          >>
          >> I have a MDB using a REMOTE DESTINATION to get the messages. The
          >> remote destination is a Topic using a Connection factory set up as
          >> following:
          >> User Transactions Enabled = true
          >> XAConnection Factory Enabled = true
          >>
          >> The MDB is set to type-transaction=Container and has a durable
          >> suscription for the Topic.
          >>
          >> Although, I know I´m using distributed transaction (XAConnection
          >> Factory Enabled = true) I am not sure if it is correct or not.
          >> I read that a distributed transaction is when you have 2 resources
          >> participating in the transaction, but, as you can see I have just JMS
          >> involved.
          >>
          >> Should I use distributed transaction or not ?
          >>
          >> Any comments will be appreciated!
          >> Thanks,
          >> Edith Rivera
          >>
          >>
          >

JMS Durable Distributed Topics

 Please forgive my ignorance if I am doing something silly. I am new to Weblogic
 and JMS, but learning a lot quickly. Any help will be greatly appreciated.
 I am running weblogic 8.1 with no service packs in a development environment only.
 We are trying to work out what is the expected behaviour for our current JMS Topic
 framework.
 I have a two server cluster with distributed topics configured. The two topics
 are configured to be durable. I have a test which generates about 100 events for
 test purposes. Under normal circumstances, each server processes about 50 messages.
 (Load balancing!)
 When the test is running, I kill one of the servers manually before it finishes.
 (Not a gracefull shutdown). The killed server processes about 20 messages, and
 the running server processes about 50. I can see that tables for the persistent
 topics have something (I don't know what) representing about all 100 events sent.
 When I bring the killed server back up, nothing happens. I would expect, from
 the documentation that I read, that the remaining 30 or so events will be put
 on the topic to be processed by our MDBs.
 Why don't all the events get placed on the topic of the killed server when it
 starts back up?
 What is the expected behaviour here?
 Is something wrong with my topic setup?
 Thanks in advance for any help...
 regards,
 Patrick Parato


Hi Patrick,
 Note 1: If you desire MDB to be transactional. Make sure
 the assembly descriptor in ejb-jar.xml is set to
 "Required" in addition to making the transaction-type
 "Container" as you have already done.
 <assembly-descriptor>
 <container-transaction>
 <method>
 <ejb-name>YOUREJBNAME</ejb-name>
 <method-name>onMessage()</method-name>
 </method>
 <trans-attribute>Required</trans-attribute>
 </container-transaction>
 </assembly-descriptor>
 Note 2: Your MDB is non-durable. It needs to be durable
 to cause messages to persist. Add the following line
 in the message-driven-destination clause of your ejb-jar.xml:
 <subscription-durability>Durable</subscription-durability>
 See the JMS FAQ on dev2dev.bea.com (or the JMS Performance
 Guide white-paper) for information on how to make
 sure a message is persistent.
 Note 3: Only one durable subscriber MDB will
 be able to attach to a given durable subscription, MDB's
 on other servers won't be able to, so even if the MDB
 is targeted at the cluster only one MDB will be able
 to process messages. This is the nature
 of durable subscriptions. I'm attaching some personal
 notes on the subject.
 Note 4: Durable subscriptions must refer to
 the JNDI name of member destinations, not to
 the distributed destination. WL does not support
 durable subscriptions directly on a distributed topic.
 Note 5: If you do not want message replication I'm not
 sure why you are using a distributed topic. Use a
 distributed queue.
 Tom
 Patrick Parato wrote:
 > Tom,
 >
 > Thanks for the quick reply.
 >
 > The first thing I want to clarify is that we only have one subscriber (MDB) that
 > is deployed once across multiple servers in a cluster. So this may explain why
 > each server is getting half the messages.
 Its still not clear. Each MDB pool should get each message.
 The individual
 instances in the pool will divide the messages sent to their MDB
 pool's subscription among them.
 >
 >
 >>2) Make sure that you are using durable subscribers. I suspect you
 >>are not. Note that durable subscribers are not supported
 >>for distributed destinations - they must refer directly to a member
 >>destination instead.
 >>
 >
 >
 > We are definitely using a distributed topic. The entry for our MDB in the weblogic-ejb.jar.xml
 > for the <destination-jndi-name> refers to the jndi name of the distributed topic.
 > So if I understand you correctly you are saying that the <destination-jndi-name>
 > should refer to the jndi name of an actual phyiscal topic on one of the servers.
 > By tying an MDB to a regular topic, how do we achieve failover if the JMS server
 > that the topic is associated with should fail?
 >
 >
 >
 > Here is a snippet of our config.xml:
 > (Names have been changed for security reasons)
 >
 > <JMSServer Name="JMS Server1" Store="Event Store1" Targets="myserver1">
 > <JMSTopic CreationTime="1065029382062"
 > JNDIName="distributed.topic@JMS Server1"
 > JNDINameReplicated="false"
 > Name="Distributed Topic@JMS Server1"
 > Template="Distributed Topic" TimeToDeliverOverride="5000"/>
 > </JMSServer>
 >
 > <JMSServer Name="JMS Server2" Store="Event Store2" Targets="myserver2">
 > <JMSTopic CreationTime="1065029382375"
 > JNDIName="distributed.topic@JMS Server2"
 > JNDINameReplicated="false"
 > Name="Distributed Topic@JMS Server2"
 > Template="Distributed Topic" TimeToDeliverOverride="5000"/>
 > </JMSServer>
 >
 >
 > <JMSDistributedTopic JNDIName="distributed.topic" Name="Distributed Topic" Targets="Cluster">
 > <JMSTemplate DeliveryModeOverride="Persistent"
 > Name="Distributed Topic" TimeToDeliverOverride="5000"/>
 > <JMSDistributedTopicMember
 > JMSTopic="distributed.topic@JMS Server1" Name="Distributed Topic@JMS
 > Server1"/>
 > <JMSDistributedTopicMember
 > JMSTopic="distributed.topic@JMS Server2" Name="Distributed Topic@JMS
 > Server2"/>
 > </JMSDistributedTopic>
 >
 >
 > ejb-jar.xml:
 >
 > <message-driven>
 > <ejb-name>AnMDB</ejb-name>
 > <ejb-class>package.AnMDB</ejb-class>
 > <transaction-type>Container</transaction-type>
 > <message-driven-destination>
 > <destination-type>
 > javax.jms.Topic
 > </destination-type>
 > </message-driven-destination>
 > </message-driven>
 >
 > weblogic-ejb.jar.xml:
 >
 > <weblogic-enterprise-bean>
 > <ejb-name>AnMDB</ejb-name>
 > <message-driven-descriptor>
 > <destination-jndi-name>distributed.topic</destination-jndi-name>
 > </message-driven-descriptor>
 > <enable-call-by-reference>True</enable-call-by-reference>
 > <jndi-name>ejb.AnMDB</jndi-name>
 > </weblogic-enterprise-bean>
 >
 > Thanks for you help and quick reply.
 >
 > regards,
 > Patrick Parato
 >
 A durable topic subscriber MDB uses its name to generate its client-id.
 Since JMS enforces uniqueness on this client-id, this means that if a durable
 subscriber MDB is deployed to multiple servers only one server will be able
 to connect. Some applications want a different behavior where
 each MDB pool on each server gets its own durable subscription.
 The MDB durable subscription id, which must be unique on its topic, comes from:
 1) <jms-client-id>MyClientID</jms-client-id>
 (the weblogic dtd)
 2) if (1) is not set then the client-id
 comes from the ejb name.
 The durable subscription is uniquely identified within a cluster by a
 combination of "connection-id" and "subscription-id". Only one active
 connection may use a particular "connection-id" within a WebLogic cluster.
 The connection id comes from:
 1) The "ClientId" attribute configured on the WebLogic connection factory.
 This defaults to null. Note that if the ClientId is set on a connection
 factory, only one connection created by the factory
 may be active at a time.
 2) If (1) is not set, then, as with the subscriber-id,
 the connection-id is derived from jms-client-id descriptor attribute:
 <jms-client-id>MyClientID</jms-client-id>
 (the weblogic dtd)
 3) If (1) and (2) are not set, then, as with the subscriber-id,
 the connection-id is derived from the ejb name.
 Work-around:
 A) Create a custom connection-factory for each server:
 1) configure "JNDIName" to the same value across all servers
 ("myMDBCF" in this example)
 2) configure "ClientId" to a unique value per server
 3) enable "UserTransactionsEnabled"
 4) enable "XAConnectionFactoryEnabled"
 5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
 6) target the CF at a single WebLogic server
 (Number 5 is required for non-transactional topic MDBs)
 B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection
 factory to the JNDI name of the custom connection factories configured in
 (A). Optionally, also specify the subscriber-id via the jms-client-id
 attribute.
 <weblogic-ejb-jar>
 <weblogic-enterprise-bean>
 <ejb-name>exampleBean</ejb-name>
 <message-driven-descriptor>
 <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
 <jms-client-id>myClientID</jms-client-id>
 </message-driven-descriptor>
 </weblogic-enterprise-bean>
 </weblogic-ejb-jar>
 C) Target the application at the same servers that have the custom connection
 factories targeted at them.
 Notes/Limitations:
 1) If the MDB is moved from one server to another, the MDB's corresponding
 connection-factory must be moved with it.
 2) This work-around will not work if the destination is not in the same
 cluster as the MDB. (The MDB can not use the local connection factory, which
 contains the connection-id, as connection factories do not work unless they
 are in the same cluster as the destination.)
 3) This work-around will not work for non-WebLogic JMS topics.

Clustered Durable MDB on Clustered JMS

Hi all
 we have an exception when trying deploy durable MDB in a cluster (WLS 7.0 SP3)
 the cluster have 2 instances. When we depploy Jar on cluster, the first MDB connect successfully, but on the other instances of cluster failed. It's possible couse use the same CLientID?
 This is the exception :
 <7-lug-05 10.54.23 CEST> <Warning> <EJB> <010061> <The Message-Driven EJB: Subsciber2 is unable to connect to the JMS destination: jms/myTopic. The EJB container will automatically attempt to re-establish the connection with the JMS server. This warning may occur during WebLogic Cluster start-up if the JMS destination is located on another server. When the JMS server connection is re-established, the Message-Driven EJB will again receive JMS messages.
 The Error was:
 weblogic.jms.common.InvalidClientIDException: Client id, null, was rejected by the leader
 how can resolve it, using the same client-id?

Hi all
 we have an exception when trying deploy durable MDB in a cluster (WLS 7.0 SP3)
 the cluster have 2 instances. When we depploy Jar on cluster, the first MDB connect successfully, but on the other instances of cluster failed. It's possible couse use the same CLientID?
 This is the exception :
 <7-lug-05 10.54.23 CEST> <Warning> <EJB> <010061> <The Message-Driven EJB: Subsciber2 is unable to connect to the JMS destination: jms/myTopic. The EJB container will automatically attempt to re-establish the connection with the JMS server. This warning may occur during WebLogic Cluster start-up if the JMS destination is located on another server. When the JMS server connection is re-established, the Message-Driven EJB will again receive JMS messages.
 The Error was:
 weblogic.jms.common.InvalidClientIDException: Client id, null, was rejected by the leader
 how can resolve it, using the same client-id?

JMS Distributed Transactions

I need to perform a distributed transaction in My Servlet.
My distributed transaction involves Updating to the DB and also publishing a message to a queue.
The queue is not present in my app server, where my Servlet is running.
It is there on a remote machine.
I'm using below code to achieve the same.
But I'm not getting the transactional behaviour working... That means
If I publish a message to queue and then if DB Operation fails, the transaction should roll back and the queue should not be having any contents.
But my queue is still showing me the contents...
Any glitches in my code???
public class RemoteServlet extends javax.servlet.http.HttpServlet implements
 javax.servlet.Servlet {
 private QueueConnectionFactory queueConnectionFactory;
 private Queue queue;
 private QueueConnection queueConnection = null;
 private QueueSession queueSession = null;
 private QueueSender queueSender = null;
 private TextMessage message = null;
 @Resource
 UserTransaction utx;
 protected void doBatch(HttpServletRequest request,
 HttpServletResponse response) throws Exception {
 try {
 initQueue();
 utx.begin();
 publishMessage(false);
 updateDB();//Some DB Operation which will fail to test the rollback
 utx.commit();
 } catch (Exception e) {
 utx.rollback();
 e.printStackTrace();
 } finally {
 closeJMS();
 printQueue();
 private void closeJMS() {
 try {
 queueSession.close();
 queueConnection.close();
 } catch (JMSException jmse) {
 jmse.printStackTrace();
 private void publishMessage() throws Exception {
 for ( int i = 1; i < 5; i++) {
 message = queueSession.createTextMessage();
 message.setText("Current Time is (" + (new Date().getTime() + i) + "):: " + new Date());
 System.out.println(" " + "Sending message :: " + message.getText());
 queueSender.send(message);
 public void initQueue() throws Exception {
 Context ctx = getInitialContext();
 Object obj = null;
 try {
 queueConnectionFactory = (QueueConnectionFactory) ctx.lookup("jmsfactory/default/MyQueueConnectionFactoryXA");
 queue = (Queue) ctx.lookup("jmsqueues/default/MyQueue");
 queueConnection = queueConnectionFactory.createQueueConnection();
 queueSession = queueConnection.createQueueSession(true, Session.AUTO_ACKNOWLEDGE);
 queueSender = queueSession.createSender(queue);
 queueConnection.start();
 } catch (Exception e) {
 e.printStackTrace();
 public void printQueue(String desc) {
 try {
 QueueBrowser browser = queueSession.createBrowser(queue);
 Enumeration<TextMessage> en = browser.getEnumeration();
 while (en.hasMoreElements()) {
 TextMessage queueBrMessage = en.nextElement();
 System.out .println( " " + queueBrMessage.getText());
 } catch (JMSException e) {
 e.printStackTrace();
 public Context getInitialContext() throws Exception {
 Properties properties = new Properties();
 properties.put(Context.INITIAL_CONTEXT_FACTORY, "com.sap.engine.services.jndi.InitialContextFactoryImpl");
 properties.put(Context.PROVIDER_URL, "10.134.162.75:50004"); // IP Address of the Host where the Queue is setup
 properties.put(Context.SECURITY_PRINCIPAL, "Administrator");
 properties.put(Context.SECURITY_CREDENTIALS, "password");
 properties.put("force_remote", "true");
 InitialContext context = new InitialContext(properties);
 return context;
 public RemoteServlet() {
 super();
 protected void doGet(HttpServletRequest request,
 HttpServletResponse response) throws ServletException, IOException {
 try {
 doBatch(request, response);
 } catch (Exception e) {
 e.printStackTrace();

A "resource adapter" is a JavaEE component used by modern application servers for linking to an external resource such as a JMS provider or database. It will wrap the XAQueueConnection for you and take care of enlisting the resources, performing two-phase commit, etc. - basically hiding all the complexities of XA transactions from you.
Nigel

"in-doubt distributed transaction" (WLS 8.1 SP2/Oracle 9.2.0.4)

 I've developed an MDB that reads a message from a queue, performs database updates
 against up to 2 databases, and sends an outgoing JMS message when all is complete.
 The MDB uses container-managed transactions to ensure that all DB updates and
 JMS messages are committed or rolled back together. I have had a lot of problems
 related to transactions failing, becoming "in-doubt" in the database and locking
 database resources indefinitely.
 My environment is configured as follows:
 WebLogic 8.1.2 Server
 Oracle 9.2.0.4 database with RAC
 XA Connection Pool with WebLogic Type 2 Oracle Driver OR Oracle 9.2.0.4
 OCI Driver
 I have read the BEA/HP white paper regarding Weblogic 8.1 with Oracle 9i RAC (http://dev2dev.bea.com/products/wlserver81/whitepapers/wls_bea_hp.jsp)
 and have tried all of the solutions suggested in that paper. The only solution
 that worked consistently without causing the in-doubt transactions was to change
 my connection pools to point directly to a single node of the RAC cluster, not
 to the shared instance. However, even with this configuration, I have seen these
 errors occur when certain database failures occur.
 A side-effect of this problem is that the associated WebLogic connection pools
 begin to "forget" connections. The pool thinks that all of the connections are
 in use (even though I am always calling Statement.close() and Connection.close()),
 and the connection pool cannot be reset manually. The only way to clear the connection
 pool is to bounce WebLogic.
 The only posts I have found related to this error were regarding Oracle 8.1.7
 and WebLogic 6.1. Any help would be greatly appreciated.
 Exceptions:
 <Mar 23, 2004 2:59:36 PM EST> <Error> <EJB> <BEA-010026> <Exception occurred during
 commit of transaction Xid=BEA1-0526A28664707F28EDB9(6412513),Status=Rolled back.
 [Reason=javax.transaction.xa.XAException
 : prepare failed for XAResource 'ProfilingPool' with error XAER_NOTA : The XID
 is not valid],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=2,seconds
 left=60,XAServerResourceInfo[JMS_my
 JmsStore]=(ServerResourceInfo[JMS_myJmsStore]=(state=rolledback,assigned=myserver),xar=JMS_myJmsStore),XAServerResourceInfo[ProfilingPool]=(ServerResourceInfo[ProfilingPool]=(state=rolledback,ass
 igned=myserver),xar=ProfilingPool),SCInfo[mydomain+myserver]=(state=rolledback),local
 properties=({}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=myserver+10.41.0.61:7001+m
 ydomain+t3+, XAResources={JMS_myJmsStore, JMS_FileStore, ProfilingPool, SearchManagementPool,
 AnnouncementsTxPool},NonXAResources={})],CoordinatorURL=myserver+10.41.0.61:7001+mydomain+t3+):
 javax.tran
 saction.xa.XAException: prepare failed for XAResource 'ProfilingPool' with error
 XAER_NOTA : The XID is not valid
 at weblogic.jdbc.oci.xa.XA.createException(XA.java:386)
 at weblogic.jdbc.oci.xa.XADataSource.internalPrepare(XADataSource.java:905)
 at weblogic.jdbc.oci.xa.XADataSource.prepare(XADataSource.java:885)
 at weblogic.jdbc.jta.DataSource.prepare(DataSource.java:846)
 at weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerResourceInfo.java:1167)
 at weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerResourceInfo.java:401)
 at weblogic.transaction.internal.ServerSCInfo$1.execute(ServerSCInfo.java:253)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
 --------------- nested within: ------------------
 weblogic.transaction.RollbackException: Could not prepare resource 'ProfilingPool
 prepare failed for XAResource 'ProfilingPool' with error XAER_NOTA : The XID is
 not valid - with nested exception:
 [javax.transaction.xa.XAException: prepare failed for XAResource 'ProfilingPool'
 with error XAER_NOTA : The XID is not valid]
 at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1644)
 at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:300)
 at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:221)
 at weblogic.ejb20.internal.MDListener.execute(MDListener.java:412)
 at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
 at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
 at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
 at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
 2004-03-23 15:00:45,406 ERROR IS003989 [ExecuteThread: '17' for queue: 'ProfileCompleteListenerBean.ExecuteQueue']
 my.package.search.business.ProfiledHoldingDAO.setProfilingStatus(ProfiledHoldingDAO.java:350
 ) - Failed to update profiling status for holding 10014 [] (-2)
 java.sql.SQLException: ORA-02049: timeout: distributed transaction waiting for
 lock
 at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:282)
 at weblogic.jdbc.oci.PreparedStatement.executeUpdate(PreparedStatement.java:226)
 at weblogic.jdbc.oci.xa.PreparedStatement.executeUpdate(PreparedStatement.java:81)
 at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:94)
 at my.package.search.business.ProfiledHoldingDAO.setProfilingStatus(ProfiledHoldingDAO.java:345)
 at my.package.search.business.ProfilingManager.disseminateAndAcknowledge(ProfilingManager.java:254)
 at my.package.search.business.ProfileCompleteListenerBean.onMessage(ProfileCompleteListenerBean.java:128)
 at weblogic.ejb20.internal.MDListener.execute(MDListener.java:382)
 at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
 at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
 at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
 at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
 2004-03-23 15:01:43,093 ERROR IS003989 [ExecuteThread: '18' for queue: 'HoldingStatusListenerBean.ExecuteQueue']
 my.package.search.business.ProfiledHoldingDAO.getProfilingStatus(ProfiledHoldingDAO.java:265)
 - Failed to retrieve profiling results for holding 10060 [] (-2)
 java.sql.SQLException: ORA-01591: lock held by in-doubt distributed transaction
 189.47.12
 at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:282)
 at weblogic.jdbc.oci.PreparedStatement.executeQuery(PreparedStatement.java:152)
 at weblogic.jdbc.oci.xa.PreparedStatement.executeQuery(PreparedStatement.java:48)
 at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:80)
 at my.package.search.business.ProfiledHoldingDAO.getProfilingStatus(ProfiledHoldingDAO.java:256)
 at my.package.search.business.ProfiledHoldingDAO.storeHoldingMetadata(ProfiledHoldingDAO.java:489)
 at my.package.search.business.ProfiledHoldingDAO.storeNewHolding(ProfiledHoldingDAO.java:406)
 at my.package.search.business.ProfilingManager.profileHolding(ProfilingManager.java:128)
 at my.package.search.business.HoldingStatusListenerBean.onMessage(HoldingStatusListenerBean.java:121)
 at weblogic.ejb20.internal.MDListener.execute(MDListener.java:382)
 at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
 at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
 at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
 at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)


Hi. There is a serious bug in the Oracle DBMS (all versions) where in-doubt
 transactions have their data locked in the DBMS by page rather than by row,
 so it will indefinitely prevent access to all data on the page, including
 logically uninvolved data. Oracle understands the problem but currently
 says they will never fix it (it would take too much work). They offer the
 alternative that you configure your table data to ensure that no more than
 one datarow resides on a page.
 Joe
 Matt Smith wrote:
 > I've developed an MDB that reads a message from a queue, performs database updates
 > against up to 2 databases, and sends an outgoing JMS message when all is complete.
 > The MDB uses container-managed transactions to ensure that all DB updates and
 > JMS messages are committed or rolled back together. I have had a lot of problems
 > related to transactions failing, becoming "in-doubt" in the database and locking
 > database resources indefinitely.
 >
 > My environment is configured as follows:
 > WebLogic 8.1.2 Server
 > Oracle 9.2.0.4 database with RAC
 > XA Connection Pool with WebLogic Type 2 Oracle Driver OR Oracle 9.2.0.4
 > OCI Driver
 >
 > I have read the BEA/HP white paper regarding Weblogic 8.1 with Oracle 9i RAC (http://dev2dev.bea.com/products/wlserver81/whitepapers/wls_bea_hp.jsp)
 > and have tried all of the solutions suggested in that paper. The only solution
 > that worked consistently without causing the in-doubt transactions was to change
 > my connection pools to point directly to a single node of the RAC cluster, not
 > to the shared instance. However, even with this configuration, I have seen these
 > errors occur when certain database failures occur.
 >
 > A side-effect of this problem is that the associated WebLogic connection pools
 > begin to "forget" connections. The pool thinks that all of the connections are
 > in use (even though I am always calling Statement.close() and Connection.close()),
 > and the connection pool cannot be reset manually. The only way to clear the connection
 > pool is to bounce WebLogic.
 >
 > The only posts I have found related to this error were regarding Oracle 8.1.7
 > and WebLogic 6.1. Any help would be greatly appreciated.
 >
 > Exceptions:
 > -----------------
 > <Mar 23, 2004 2:59:36 PM EST> <Error> <EJB> <BEA-010026> <Exception occurred during
 > commit of transaction Xid=BEA1-0526A28664707F28EDB9(6412513),Status=Rolled back.
 > [Reason=javax.transaction.xa.XAException
 > : prepare failed for XAResource 'ProfilingPool' with error XAER_NOTA : The XID
 > is not valid],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=2,seconds
 > left=60,XAServerResourceInfo[JMS_my
 > JmsStore]=(ServerResourceInfo[JMS_myJmsStore]=(state=rolledback,assigned=myserver),xar=JMS_myJmsStore),XAServerResourceInfo[ProfilingPool]=(ServerResourceInfo[ProfilingPool]=(state=rolledback,ass
 > igned=myserver),xar=ProfilingPool),SCInfo[mydomain+myserver]=(state=rolledback),local
 > properties=({}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=myserver+10.41.0.61:7001+m
 > ydomain+t3+, XAResources={JMS_myJmsStore, JMS_FileStore, ProfilingPool, SearchManagementPool,
 > AnnouncementsTxPool},NonXAResources={})],CoordinatorURL=myserver+10.41.0.61:7001+mydomain+t3+):
 > javax.tran
 > saction.xa.XAException: prepare failed for XAResource 'ProfilingPool' with error
 > XAER_NOTA : The XID is not valid
 > at weblogic.jdbc.oci.xa.XA.createException(XA.java:386)
 > at weblogic.jdbc.oci.xa.XADataSource.internalPrepare(XADataSource.java:905)
 > at weblogic.jdbc.oci.xa.XADataSource.prepare(XADataSource.java:885)
 > at weblogic.jdbc.jta.DataSource.prepare(DataSource.java:846)
 > at weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerResourceInfo.java:1167)
 > at weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerResourceInfo.java:401)
 > at weblogic.transaction.internal.ServerSCInfo$1.execute(ServerSCInfo.java:253)
 > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
 > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
 > --------------- nested within: ------------------
 > weblogic.transaction.RollbackException: Could not prepare resource 'ProfilingPool
 > prepare failed for XAResource 'ProfilingPool' with error XAER_NOTA : The XID is
 > not valid - with nested exception:
 > [javax.transaction.xa.XAException: prepare failed for XAResource 'ProfilingPool'
 > with error XAER_NOTA : The XID is not valid]
 > at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1644)
 > at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:300)
 > at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:221)
 > at weblogic.ejb20.internal.MDListener.execute(MDListener.java:412)
 > at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
 > at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
 > at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
 > at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
 > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
 > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
 > ...
 > 2004-03-23 15:00:45,406 ERROR IS003989 [ExecuteThread: '17' for queue: 'ProfileCompleteListenerBean.ExecuteQueue']
 > my.package.search.business.ProfiledHoldingDAO.setProfilingStatus(ProfiledHoldingDAO.java:350
 > ) - Failed to update profiling status for holding 10014 [] (-2)
 > java.sql.SQLException: ORA-02049: timeout: distributed transaction waiting for
 > lock
 > at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:282)
 > at weblogic.jdbc.oci.PreparedStatement.executeUpdate(PreparedStatement.java:226)
 > at weblogic.jdbc.oci.xa.PreparedStatement.executeUpdate(PreparedStatement.java:81)
 > at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:94)
 > at my.package.search.business.ProfiledHoldingDAO.setProfilingStatus(ProfiledHoldingDAO.java:345)
 > at my.package.search.business.ProfilingManager.disseminateAndAcknowledge(ProfilingManager.java:254)
 > at my.package.search.business.ProfileCompleteListenerBean.onMessage(ProfileCompleteListenerBean.java:128)
 > at weblogic.ejb20.internal.MDListener.execute(MDListener.java:382)
 > at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
 > at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
 > at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
 > at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
 > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
 > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
 > ...
 > 2004-03-23 15:01:43,093 ERROR IS003989 [ExecuteThread: '18' for queue: 'HoldingStatusListenerBean.ExecuteQueue']
 > my.package.search.business.ProfiledHoldingDAO.getProfilingStatus(ProfiledHoldingDAO.java:265)
 > - Failed to retrieve profiling results for holding 10060 [] (-2)
 > java.sql.SQLException: ORA-01591: lock held by in-doubt distributed transaction
 > 189.47.12
 > at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:282)
 > at weblogic.jdbc.oci.PreparedStatement.executeQuery(PreparedStatement.java:152)
 > at weblogic.jdbc.oci.xa.PreparedStatement.executeQuery(PreparedStatement.java:48)
 > at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:80)
 > at my.package.search.business.ProfiledHoldingDAO.getProfilingStatus(ProfiledHoldingDAO.java:256)
 > at my.package.search.business.ProfiledHoldingDAO.storeHoldingMetadata(ProfiledHoldingDAO.java:489)
 > at my.package.search.business.ProfiledHoldingDAO.storeNewHolding(ProfiledHoldingDAO.java:406)
 > at my.package.search.business.ProfilingManager.profileHolding(ProfilingManager.java:128)
 > at my.package.search.business.HoldingStatusListenerBean.onMessage(HoldingStatusListenerBean.java:121)
 > at weblogic.ejb20.internal.MDListener.execute(MDListener.java:382)
 > at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:316)
 > at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
 > at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
 > at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
 > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
 > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
 >
 >

Lock held by in-doubt distributed transaction

 I'm having an intermittent problem in our server where a distributed transaction
 between WebLogic JMS (6.1 sp3) and Oracle (using the 9.1.2 XA driver) doesn't
 complete and subsequent attempts to access the rows in question result in:
 java.sql.SQLException: ORA-01591: lock held by in-doubt distributed transaction
 4.33.52658
 Has anybody else seen anything like this?


 Rao,
 The BEA patch is CR095835_610SP4. Apparently there is a corresponding patch for
 SP3 as well. When configuring the jdbc connection pool set XaSetTransactionTimeout
 = true and
 XaTransactionTimeout = yourTimeoutValueInSeconds. This will instruct the Transaction
 manager to set the timeout value on Oracle's XAResource during the two-phase commit
 process. I believe Oracle refers to the timeout value as SesTm.
 Cheers,
 Tony
 "Rao Boppana" <[email protected]> wrote:
 >
 >We are currently facing the same problem. Could you let us know more
 >details about
 >the patch BEA put out to fix this? Is there a patch #/bug #? We are currently
 >running SP4, Oracle 9.2.3 using 9.2.0.1 drivers. We really cannot set
 >our JTA
 >timeout to less than 1 minute and hence we are left with option2. Any
 >help would
 >be greatly appreciated.
 >
 >
 >"Tony Necakov" <[email protected]> wrote:
 >>
 >>Jane,
 >>Thanks for the reply. After talking to Oracle support, we believe we've
 >>discovered
 >>the cause of the problem. Apparently, setting the JTA transaction timeout
 >>does
 >>not affect the default timeout from Oracle's point of view. Consequently,
 >> XA
 >>transactions exceeding 1 minute (Oracle's default) were being marked
 >>by Oracle
 >>as in-doubt. Subsequent commits or rollback from the transaction manager
 >>were
 >>being ignored. The solution is to either knock the JTA timeout value
 >>to something
 >>below Oracle's default or install a BEA patch which allows the transaction
 >>manager
 >>to set the timeout on the Oracle resource manager.
 >>
 >>"Jane Sampson" <[email protected]> wrote:
 >>>Hi Tony,
 >>>
 >>>Yes, I believe there were some problems with 8.1.7. I believe it requires
 >>>an Oracle patch AND a JDriver patch (if you are using the WebLogic
 >JDriver).
 >>>Open a case with support for details.
 >>>
 >>>Thanks,
 >>>
 >>>Jane
 >>>BEA Support
 >>>
 >>>
 >>>"Tony Necakov" <[email protected]> wrote in message
 >>>news:[email protected]...
 >>>>
 >>>> We're seeing the same intermittent problem with Oracle 8.1.7.2 and
 >>>8.1.7.4. The
 >>>> problem occurs with WLS 6.1 service pack 3 and service pack 4.
 >>>>
 >>>> "Jane Sampson" <[email protected]> wrote:
 >>>> >Hi Tim,
 >>>> >
 >>>> >There is an issue has been reported for Oracle 9.2.0.1 Database/Oracle
 >>>> >9.2.0.1 Thin Driver and exhibits this behavior and is being address
 >>>by
 >>>> >both
 >>>> >BEA and Oracle. I would suggest you open a case with Customer Support
 >>>> >and
 >>>> >mention CR090816. It could be the same problem.
 >>>> >
 >>>> >Thanks,
 >>>> >
 >>>> >Jane
 >>>> >BEA Support
 >>>> >
 >>>> >"Tim Dawson" <[email protected]> wrote in message
 >>>> >news:[email protected]...
 >>>> >>
 >>>> >> I'm having an intermittent problem in our server where a distributed
 >>>> >transaction
 >>>> >> between WebLogic JMS (6.1 sp3) and Oracle (using the 9.1.2 XA
 >driver)
 >>>> >doesn't
 >>>> >> complete and subsequent attempts to access the rows in question
 >>>result
 >>>> >in:
 >>>> >>
 >>>> >> java.sql.SQLException: ORA-01591: lock held by in-doubt distributed
 >>>> >transaction
 >>>> >> 4.33.52658
 >>>> >>
 >>>> >> Has anybody else seen anything like this?
 >>>> >
 >>>> >
 >>>>
 >>>
 >>>
 >>
 >

ORA-01591: lock held by in-doubt distributed transaction 14.4.44

Hi,
I am using WLI 8.1 SP2 on Windows 2000, Oracle 9.2. I am getting this error...
<Apr 23, 2004 10:43:43 AM EDT> <Error> <WLW> <000000> <error
java.io.IOException: [BEA][Oracle JDBC Driver][Oracle]ORA-01591: lock held by
in
-doubt distributed transaction 14.4.44
at weblogic.jdbc.base.BaseBlobOutputStream.write(Unknown Source)
at weblogic.jdbc.base.BaseBlobOutputStream.write(Unknown Source)
at com.bea.wlw.runtime.core.bean.BMPContainerBean$OracleTableAccess.doSt
oreByInsert(BMPContainerBean.java:904)
at com.bea.wlw.runtime.core.bean.BMPContainerBean.doInsert(BMPContainerB
ean.java:1785)
at com.bea.wlw.runtime.core.bean.BMPContainerBean.ejbStore(BMPContainerB
ean.java:1742)
at com.bea.wli.bpm.runtime.ProcessContainerBean.ejbStore(ProcessContaine
rBean.java:79)
at com.bea.wlwgen.PersistentContainer_nga2bb_Impl.ejbStore(PersistentCon
tainer_nga2bb_Impl.java:149)
at weblogic.ejb20.manager.ExclusiveEntityManager.beforeCompletion(Exclus
iveEntityManager.java:556)
at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManag
er.java:745)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(Serv
erSCInfo.java:1010)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(Se
rverSCInfo.java:115)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAn
dChain(ServerTransactionImpl.java:1142)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(
ServerTransactionImpl.java:1868)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(Se
rverTransactionImpl.java:250)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTran
sactionImpl.java:221)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:412)
at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.
java:316)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
I have tried dropping all wli tables & deleting tlog files (deleting everything
from cgServer directory). Still get this error.
Any suggestions??
TIA
-Amit

Getting this problem with WLI. I have just truncated tables and it's fine now.
Thanks,
Amit
"Sheetal Jain" <[email protected]> wrote:
>
Amit,
If these problem is happening with the WLI database then I would suggest
you should
talk to BEA support. If it is happening in the application you have built
just
look for any deadlock conditions happening in some scenarios inside different
inter-related transactions running at the same time, I mean transaction
1 is locking
something and in the meantime another one B locks something else which
is required
for the transaction A to move farward and now second one needs the resource
locked
by 1st.
Hope this helps
"Nagraj Rao" <[email protected]> wrote:
Hello Amit !,
Lock From In-Doubt Transaction is a 2-p TX issue, A query or DML statement
that
requires locks on a database is probably blocked due to some lock held
by a resource
of an "in-doubt distributed transaction".
A DB Admin can manually Commit or Rollback an "in-doubt distributedtransaction".
So I suggest you talk to the DBA
More at : http://www-rohan.sdsu.edu/doc/oracle/server803/A54653_01/ds_ch3.htm
BTW here's what Oracle says :
ORA-01591 lock held by in-doubt distributed transaction string
Cause: An attempt was made to access resource that is locked by a dead
two-phase
commit transaction that is in prepared state.
Action: The database administrator should query the PENDING_TRANS$ and
related
tables, and attempt to repair network connection(s) to coordinator and
commit
point. If timely repair is not possible, the database administratorshould
contact
the database administrator at the commit point if known or the end user
for correct
outcome, or use heuristic default if given to issue a heuristic COMMIT
or ABORT
command to finalize the local portion of the distributed transaction.
"Sheetal Jain" <[email protected]> wrote:
Amit,
It could be a bug. Open a ticket with BEA and see if they have a patch.
"Amit Bhutra" <[email protected]> wrote:
Hi,
I am using WLI 8.1 SP2 on Windows 2000, Oracle 9.2. I am getting
this
error...
<Apr 23, 2004 10:43:43 AM EDT> <Error> <WLW> <000000> <error
java.io.IOException: [BEA][Oracle JDBC Driver][Oracle]ORA-01591: lock
held by
in
-doubt distributed transaction 14.4.44
at weblogic.jdbc.base.BaseBlobOutputStream.write(Unknown Source)
at weblogic.jdbc.base.BaseBlobOutputStream.write(Unknown Source)
at com.bea.wlw.runtime.core.bean.BMPContainerBean$OracleTableAccess.doSt
oreByInsert(BMPContainerBean.java:904)
at com.bea.wlw.runtime.core.bean.BMPContainerBean.doInsert(BMPContainerB
ean.java:1785)
at com.bea.wlw.runtime.core.bean.BMPContainerBean.ejbStore(BMPContainerB
ean.java:1742)
at com.bea.wli.bpm.runtime.ProcessContainerBean.ejbStore(ProcessContaine
rBean.java:79)
at com.bea.wlwgen.PersistentContainer_nga2bb_Impl.ejbStore(PersistentCon
tainer_nga2bb_Impl.java:149)
at weblogic.ejb20.manager.ExclusiveEntityManager.beforeCompletion(Exclus
iveEntityManager.java:556)
at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManag
er.java:745)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(Serv
erSCInfo.java:1010)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(Se
rverSCInfo.java:115)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAn
dChain(ServerTransactionImpl.java:1142)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(
ServerTransactionImpl.java:1868)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(Se
rverTransactionImpl.java:250)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTran
sactionImpl.java:221)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:412)
at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.
java:316)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:281)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
I have tried dropping all wli tables & deleting tlog files (deleting
everything
from cgServer directory). Still get this error.
Any suggestions??
TIA
-Amit

EJB 3.0 and JTA (Distributed transactions)

hi, first of all sorry for my english.
then :)
i'm working with JBoss Aplication Server an Oracle DataBase using EJB 3.0
i have no problem before ... but now i want work with multiple database and i wand to manage transactions ... how i understand JTA (Java Transaction Api) is a technology for it.
i think that i need two datasource file for example oracle-xa-ds.xml and postgres-ds.xml
<datasources>
<xa-datasource>
 <jndi-name>XAOracleDS</jndi-name>
 <track-connection-by-tx/>
 <isSameRM-override-value>false</isSameRM-override-value> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
 <xa-datasource-property name="URL">jdbc:oracle:thin:@192.9.200.177:1521:devnbtwo</xa-datasource-property>
 <xa-datasource-property name="User">paata</xa-datasource-property>
 <xa-datasource-property name="Password">1982226</xa-datasource-property> <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
 <no-tx-separate-pools/>
 <metadata>
 <type-mapping>Oracle9i</type-mapping>
 </metadata>
</xa-datasource>
<mbean code="org.jboss.resource.adapter.jdbc.vendor.OracleXAExceptionFormatter"
 name="jboss.jca:service=OracleXAExceptionFormatter">
 <depends optional-attribute-name="TransactionManagerService">jboss:service=TransactionManager</depends>
</mbean>
</datasources>
<datasources>
<local-tx-datasource>
 <jndi-name>PostgresDS</jndi-name>
 <connection-url>jdbc:postgresql://localhost:5432/Test</connection-url>
 <driver-class>org.postgresql.Driver</driver-class>
 <user-name>postgres</user-name>
 <password>1982226</password>
 <new-connection-sql>select 1</new-connection-sql>
 <metadata>
 <type-mapping>PostgreSQL 7.2</type-mapping>
 </metadata>
</local-tx-datasource>
</datasources>and i dont know what should i do in my persistance.xml file ..... when i was working with single database my persistance.xml file was working
<?xml version="1.0" encoding="UTF-8" ?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
 version="1.0">
 <persistence-unit name="Oracle" transaction-type="JTA">
 <jta-data-source>java:/XAOracleDS</jta-data-source>
 <class>com.magti.businesslayer.ejb3entity.Group</class>
 <class>com.magti.businesslayer.ejb3entity.Student</class>
 <properties>
 <property name="hibernate.dialect" value="org.hibernate.dialect.OracleDialect"/>
 <property name="hibernate.connection.driver_class" value="oracle.jdbc.driver.OracleDriver"/>
 <property name="hibernate.connection.url" value="jdbc:oracle:thin:@192.9.200.177:1521:devnbtwo"/>
 <property name="hibernate.connection.username" value="paata"/>
 <property name="hibernate.connection.password" value="1982226"/>
 <property name="hibernate.default_schema" value="PAATA"/>
 </properties>
 </persistence-unit>
</persistence>but then i added anothe unit for second database and i get error
 <persistence-unit name="PostgreSql" transaction-type="JTA">
 <jta-data-source>java:/PostgresDS</jta-data-source>
 <class>com.magti.businesslayer.ejb3entity.Group</class>
 <class>com.magti.businesslayer.ejb3entity.Student</class>
 <properties>
 <property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>
 <property name="hibernate.connection.driver_class" value="org.postgresql.Driver"/>
 <property name="hibernate.connection.url" value="jdbc:postgresql://localhost:5432/Test"/>
 <property name="hibernate.connection.username" value="postgres"/>
 <property name="hibernate.connection.password" value="1982226"/>
 <property name="hibernate.default_schema" value="postgres"/>
 </properties>
 </persistence-unit> i don't know how i resolve it .
i can't find any simple exaplme about distributed transactions on net ...
can anybody help me ....
thanks.

Check this one:
http://www.webagesolutions.com/knowledgebase/javakb/jkb005/index.html

Distributed transaction (JDBC+JMS), durable MDB, NullPointException in weblogic

Similar Messages

Maybe you are looking for