2 Phase Commit Global Transaction resolution question.

Hi All,
I hope this is the right place to ask this question.
I'm trying to figure out what generally happens after the JTA AbandonTimeout occurs.
Here is the scenario.
1. Transaction Manager sends Commit to Resource Managers 1 and 2.
2. Resource Manager 1 receives and processes commit. Resource Manager 2 doesn't receive commit.
3. Resource Manager 1 returns acknowledgement.
4. Transaction Manager times out and starts recovery process.
5. Resource Manager 2 session times out and is set to in-doubt.
6. Transaction Manager can never reconnect to Resource Manager 2, and the AbandonTimeout is reached.
7. Transaction Manager abandons RM2 transaction.
8. Does Transaction manager return an error for global transaction?
I'm guessing the application the Transaction Manager is working for has its own timeouts which would most likely be a smaller value than the abandon timeout. So the transaction would most likely timeout. I'm just trying to make sure that the Global Transaction is not sent back as complete at a later time if the abandon timeout is reached.
Any Thoughts?
Thanks,
Matt

Petr-
In article <avflf9$ccu$[email protected]>, Petr Bulanek wrote:
Hi Marc,
Well, what does it really mean that \'Kodo will not respect the
semantics of the 2-phase-commit protocol\'?Are you saying that Kodo may commit my changes even if the other datastore
decides to roll the transaction back at the last moment?
That if Kodo has difficulties to commit, it would not roolback the global
transaction and as a result the other datastores will commit?You are correct: we currently do not do anything special for 2 phase
commit at all.
I mean, this is quite important and would like to know exactly what to
expect so I can work around it.
Thank you,
Petr
P.S.
I \'think\' I saw the plan to fix this in 2.5.x. What is the planned
release date?It is in the milestone for 2.5. We can't make any committments on its
release date, but it will hopefully be out within 2 months.
Marc Prud\'hommeaux wrote:
Petr-
You can integrate Kodo\'s JDO transactions into the Application Server\'s
global transaction (which might also commit multiple other
transactions). The only issue is that Kodo will not respect the
semantics of the 2-phase-commit protocol.
We expect to have this issue resolved soon.
In article <avdri3$f2o$[email protected]>, Petr Bulanek wrote:
I have noticed that there is open bug (211) that refers to 2 phase commit
and I just curious what the exact problem is.
Does that imply that the current version (2.4) does not allow 2 phase
commit?
Let\'s say I need to integrate JDO into global transaction (managed by App
server) and I may need during that transaction update multiple databases.
It could be implemented via JDO (multiple PMFs) or it could be a
combination of JDO and JDBC/EJB happening during the same transaction.
Am I likely to hit a problem if I do that?
Thank you,
Petr
Marc Prud\'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com

Similar Messages

SAP Transaction in Two phase Commit ?

Hi all,
When we make a connection to SAP system from .NET application using .NET connector, we can make calls to transactional BAPI/RFCs. But is there any way in which we can make SAP transaction take part in MS DTC (Microsoft Distributed Transaction Coordinator) transactions?
We want to implement a two phase commit and hence this question. Please let us know if you are aware of any mechanism using which we can implement a two phase commit.
The call scenario is described below:
TransactionScope
1.     SQL_StoredProc1();
2.     SQL_StoresProc2();
     10.           SAP_TransactionBAPI();
     11.          SQLStoredProcn();
      12.           SQLTransaction_Commit();
      13.      SAPTransaction_Commit();
Exception ()
SQLTransaction_Rollback();
SAPTransaction_Rollback();
In the above case all the statements have to be executed successfully or they have to be rolled back. Lets think of the situation where all the statements up to line 13 have been executed successfully, but there was a failure during the commit of SAP, and then we have to rollback the SQL transaction also which is already committed.
This situation can be handled if and only if SAP transaction manager follows XA transaction protocol and it can include itself in MSDTC. So that every transaction manager votes for the commit (it can be called half commit) if the transaction is successful otherwise all the transactions should be rolled back.
Can anybody tell me the way to include SAP transaction manager in MSDTC if it at all possible?

Hi Saket,
I did not understand much of your query but just wanted to know how are you making a connection to the backend here?
If using DataSources and if the datasource is configured directly in the EP server (using Visual Administrator), you have an option of the required 2-way commit.
The datasource takes care of it directly. Apart from this, the datasource will also take cre of the connection pooling.
Hope this helps.
Awaiting Reply.
Warm Regards,
Ritu

DISTRIBUTED TRANSACTION의 2 PHASE COMMIT 개념 및 절차

제품 : ORACLE SERVER
작성날짜 : 2002-05-15
DISTRIBUTED TRANSACTION의 2 PHASE COMMIT 개념 및 절차
====================================================
Oracle이 분산 트랜잭션 수행을 위해 사용하는 2 phase commit의 자세한 개념
및 절차를 살펴본다.
1. 용어와 개념
Oracle은 분산 트랜잭션을 수행하면서 여기에 포함된 모든 node에 대해서
session tree를 구성한다. session tree는 분산 트랜잭션에 관여되는 session과
각 session의 역할을 계층적인 tree형태로 표현한다고 볼 수 있으며,
DBA_2PC_NEIGHBORS view를 통해 확인 가능하다.
session tree에 포함되는 각 node들이 수행하는 역할은 2 phase commit 절차의
기본적인 개념이 되므로, 분산 트랜잭션의 이해를 위해서 정확히 파악할 필요가
있다. 아래에 각 역할 들의 종류와 의미를 설명하며 [그림 1]을 예로 든다.
- client
- database server
- global coordinator
- local coordinator
- commit point site
insert into seoul_tab...;
delete from pusan_tab@pusan...;
Seoul.world inchoen_procedure@incheon...;
/ \ incheon_procedure source
Pusan.world Inchoen.world ------------------------
\ delete from incheon_tab...;
\ update jeju_tab@jeju...;
Jeju.world
[그림 1] session tree의 간단한 예제
(1) client: 다른 node의 database 정보를 이용하면 client가 된다.
참조되어지는 node는 이때 database server가 된다. seoul.world가
pusan.world와 incheon.world의 client이고, incheon.world는 jeju.world의
client가 된다.
(2) server (database server): 분산 트랜잭션에 포함된 모든 node를 server라
한다. seoul.world, pusan.world, incheon.world, jeju.world 모두 database
server이다.
(3) global coordinator:분산 트랜잭션을 처음 수행시킨 node를 의미한다.
여기서는 seoul.world가 global coordinator이다.
(4) local coordinator: 분산 트랜잭션에서 이 node에 관계된 부분의 결과를
얻으려면 다른 node를 참조해야 하는 경우 이 node를 local coordinator라고
한다. 이것이 위에서 설명한 global coordinator와는 차이가 있는데 global
coordinator는 항상 local coordinator이지만, 반대로 local coordinator는
global coordinator가 아닐 수 있다.
Incheon.world의 경우 처음 문장을 수행시킨 global coordinator는 아니지만,
Incheon.world의 Inchoen_procedure내에 jeju.world가 reference되므로
local coordinator가 된다. seould.world는 global coordinator이면서
local coordinator가 된다.
(5) commit point site
commit point site는 분산 트랜잭션에 관여된 node중 2 phase commit단계에서
commit이나 rollback을 항상 제일 먼저 하게 된다. 이 node의 local
transaction부분은 prepared상태를 거치지 않아 in-doubt 상태가 되는 일이
없고, 그러므로 distributed lock에 의해 조회나 DML시 오류가 발생하는
없게 된다. 이러한 이유로 제일 중요한 data를 포함하는 중심이 되는 node를
commit point site로 지정하는 것이 바람직하다.
commit point site는 각 node의 initialization parameter중
COMMIT_POINT_STRENGTH 값을 비교하여 제일 큰 값을 가진 node가 지정된다.
두 node만 관여된 분산 트랜잭션의 경우 commit_point_strength가 지정되어
있지 않으면, default로 global coordinator가 아닌 node가 commit point
site가 된다.
2. 2 Phase Commit (2PC)
분산 트랜잭션을 commit하는 것은 다음 두 단계를 거치게 된다. 그래서 Oracle의
분산 트랜잭션은 2 phase commit mechanism을 사용한다고 한다.
prepare 단계: global coordinator (SQL문장을 처음 수행한 server) 가 commit
point site를 제외한 나머지 node에게 prepare하도록 요청한다.
요청을 받은 node는 각 local db에서의 작업에 대해 commit이나
rollback할 준비를 마치고 다시 global coordinator에게 prepare
되었음을 알려 주는 단계이다.
node가 prepare 단계를 지나고 commit을 완료하기 전까지는
transaction이 in-doubt상태라고 부른다.
commit단계: 모든 node가 정상적으로 prepare가 되면, 먼저 commit point site가
commit을 완료하고 이후 다른 node들도 commit을 완료하게 된다.
이렇게 분산 트랜잭션에서 commit을 수행하기 위해 두 단계를 거치면서 일부
node만 commit이 되고 일부는 rollback이 되는 불일치 상태를 막을 수 있는데,
그러기 위한 자세한 단계별 처리 절차를 아래 [표 1]에 17단계로 기술하였다.
각 단계별로 global coordinator와 commit point site, 그리고 둘 모두에
해당되지 않는 일반 database server입장으로 나누어 표시하였으며, 만약 어떤
node가 global coordinator이면서 commit point site라면, 두 part의 일을 모두
하게 되는 것이다.
아래 표의 (4) ~ (10)번 단계는 prepare단계의 작업이며, (11) ~ (15)번 단계는 commit단계
이다. 부가적으로 (16), (17)을 정리 단계로 부르기도 한다.
단계| Global coordinator | 참여한 db server | Commit point site
(commit point site도 아니고
global coordinator도 아닌경우)
(1) SQL문장 발생 |     |
(2) SQL문장이 수행되면 session tree가 구성되고 이 정보는
DBA_2PC_NEIGHBORS를 통해 조회 가능하다.
변경이 필요한 data는 각 node별로 자기의 local data에 대해서 lock
(TX,TM)을 걸면서 문장 수행이 진행된다.
(3) Commit; 문장 발생 |          |
(4) commit point site를 |          |
commit_point_strength |          |
initial parameter를 참조 |          |
하여 결정하고, |          |
참여한 모든 node의 SCN중 |          |
제일 큰 값을 commit SCN으로|           |
결정하고 이후에 각 node의 |          |
commit시 이용한다. |          |
(5) commit point site를 |          |
제외한 모든 node들에게 |          |
prepare하도록 요청한다 |          |
(6) prepare 요청 message받는다 |
(7) transaction이 이 node의 data를 변경하였는지를 |
확인하고, 변경 사항이 있고 commit이 가능한 |
상태이면 다음 단계를 수행하고, 그렇지 않으면 |
(10)번 단계로 건너뛴다           |
(8) transaction에 distributed lock을 걸어 fail이 |
되어도 rollback이 되지 않고 변경 사항에 lock이|
걸린 채 유지되도록 한다.           |
distributed lock이 걸려 있는 상태에서는 변경 |
data를 포함한 block에 포함된 어떤 data도 |
read/write가 불가능하게 된다 (ora-1591발생) |
[참조 1]                    |
(9) transaction에 의해 변경된 내용과 (8)번 단계의 |
information에 대한 redo log 내용을 각 node의 |
redo log file에 기록한다. (해당 node의 변경 |
사항만을 해당 node의 redo log file에 기록) |
(10) global coordinator에게 다음 세가지 중 하나의 |
상태를 prepare message대한 응답으로 전달한다.|
PREPARED:변경된 data가 있고 commit이 가능한 |
상태               |
READ-ONLY: 자신의 node에는 data 변경사항이 |
없고 조회만 관여한 경우 |
ABORT: 오류 발생으로 인해 commit이 불가능한 |
경우                     |
(11) prepare 요청 message에 | |
대한 응답 중 한 node라도| |
abort가 있으면: | |
모든 관여된 node를 | |
rollback하도록 요청하고 | |
distributed transaction | |
을 끝낸다. | |
prepare요청 message에 | |
대한 응답이 read-only나 | |
prepared만 있다면: | |
commit point site에게 | |
commit하라고 요청한다. | |
(12) | |이 node에 관여된 local
| |transaction 부분만을
| |commit 한다.
| |- data변경사항과 commit
| |정보를 local redo log
| |file에 기록한다.
| |- commit SCN은 (4)번단계
               |           |에서 얻어진, 관여된 node
               |          |의 SCN중 제일 큰 값을
| | 이용한다.
               |     |- (2) 번 단계에서 잡혔던 TX,
| | TM lock은 해제된다.
(13) |global coordinator에게
|commit이 완료되었음을
|알리는 message를 보낸다.
(14) commit point site를 제 | |
외한 다른 node들에게 | |
commit하라고 요청한다. | |
(15) commit하면서 (2)번 단계에서 잡은 TX, TM lock|
과, (8)번 단계에서 잡힌 distributed lock을 |
release하고, 이러한 commit정보를 redo log |
file에 기록한다.
(16) | |DBA_2PC_PENDING,
| |DBA_2PC_NEIGHBORS등
| |dictionary 저장된 정보를
| |지우고 global coordinator
| |에게 정보를 지웠음을
| |알려준다
(17) DBA_2PC_PENDING, DBA_2PC_NEIGHBORS 등 |
dictionary 저장된 정보를 지우고 정리한다. |
[참조 2] |
[표 1] 2 phase commit의 단계별 절차
[참조 1] distributed lock
(8)번 단계에서 기술한 distributed lock은 실제 v$lock을 확인하여서는
나타나지 않는다. v$lock에 lock type이 DX로 나타나는 것은 distributed
transaction lock으로 이것은 2 phase commit을 위한 것이 아니라
XA에서 단일 transaction내에서 여러 branch에 대한 control을
tightly-coupled 형태로 하는 경우에 사용되어 지는 것이므로, 여기서
언급하는 distributed lock과 혼동되어서는 안된다.
여기에서 설명한 distributed lock은 실제 type을 가지고 있는 lock이
아니고 해당 transaction에 대한 local db내의 rollback segment
header부분에서 transaction상태를 prepared를 나타내는 bit로
     설정함으로써 lock설정을 구현한다.
그러므로 이 lock이 걸려 있는 동안은 다른 transaction이 해당 분산
트랜잭션이 변경한 data와 같은 block의 어떠한 data라도 읽거나
쓰려고 하면, 그 block에 commit되지 않은 transaction이 있다는 것을
인식하고 before image를 읽기 위해 rollback segment를 찾게 되고,
그 rollback segment에 prepared상태로 표시되어 있어 before image
읽는 것을 막기 때문에 오류가 발생하게 된다. 이 오류가 ORA-1591이
되는 것이다.
transaction이 prepared상태로 distributed lock이 걸린 상태인지는
DBA_2PC_PENDING의 status가 PREPARED인지를 확인하는 것만이
dictionary를 통해 가능한 정보이다.
[참조 2] DBA_2PC_PENDING의 정보
DBA_2PC_PENDING view의 정보는 분산 트랜잭션이 비정상 종료 되었을
때만 정보가 저장되는 것이 아니다. 앞의 [표 1]의 2 phase commit
단계마다, 수행되는 작업에 대해서 해당 view에 계속해서 정보를
변경해 가고 앞의 표의 (16), (17) 단계를 완료해야 지워지게 된다.
분산 트랜잭션이 비정상 종료시 이 view에서 해당 transaction의
상태가 COLLECTING이나 PREPARED, COMMITTED 상태로 정보가 보여지는
것은 마지막 정리 단계 수행 전에 transaction이 종료되었기 때문이다.
     non-commit point site의 경우, (10)번 단계에서 distributed lock을
걸기 전까지는 DBA_2PC_PENDING의 STATE column 값이 COLLECTING으로
나타나게 되며, (15) 단계 수행전까지는 PREPARED로 나타나고, (17)번
     수행전까지는 COMMITTED로 나타난다.
commit point site의 경우는, (11)번 수행단계까지는 이 view에 어떠한
정보도 포함하지 않으며, (12)번 수행 후 (16)번 단계를 수행하기
전까지는 COMMITTED로 STATE 값을 가지게 된다.

Does Oracle App Server 10.1.3.1 support global transactions?

I'm asking because it seems it doesn't. My stateless EJB calls an EJB in another application server, but the transaction is not propagated. Why is that?
Does it matter which inittial context factory or which TransactionalObject?
Do the different application server vendors (Oracle, Websphere ect.) support global transactions between each other?
I cannot find anything about this in the Oracle App server documentation.
Can anyone help?

Hello,
Yes i should be possible to do.
Have you look at the OC4J transaction propagation that used the OracleAS transaction manager?
- How to list.
This will help you to configure properly your application.
Documentation:
- Data source and Global Transactions (XA)
- How do You Participate in a Global or Two-Phase Commit (2PC) Transaction?
- Configuring Transaction Service
Hope that helps...
Regards
Tugdual Grall

Scope of one phase commit optimization?

Hello,
I am unclear about the scope across which Tuxedo XA can optimize the commit to a one phase commit when there is only a single resource involved.
Is it just the process?
Or is it the group (same TM)?
Based on the XA specification, it is the connection that matters. The one phase commit is only possible if a single connection is involved.
However, in the Tuxedo case, the Transaction Manager is shared amongst all the processes in a group. Therefore, the Transaction Manager could be aware that only one Resource Manager is involved, even when the transaction spans multiple processes (within the group). Thus from the TM perspective, a one phase commit would be possible. But then again the Resource Manager would have to support that too.
The context for this is Tuxedo 11, ATMI, XA and Oracle 11g. Some transactions use /Q and DB (requiring XA and two phase commit), other transactions only affect the DB.
Thanks...
Roger

Hi Roger,
I'm not sure where the idea that one-phase commit is "only possible if a single connection is involved."? Here is the description of the one phase commit optimization from the XA specification:
"One-phase Commit
A TM can use one-phase commit if it knows that there is only one RM anywhere in
the DTP system that is making changes to shared resources. In this optimisation,
the TM makes its Phase 2 commit request without having made a Phase 1 prepare
request. Since the RM decides the outcome of the transaction branch and forgets
about the transaction branch before returning to the TM, there is no need for the TM
to record stably these global transactions and, in some failure cases, the TM may not
know the outcome."
The TM can also get back read-only from an RM on prepare and use that to decide to perform a one-phase commit if there had only been one other RM involved.
IIRC Tuxedo decides to do a one-phase commit if there is only one group involved in the transaction. So if you have two groups accessing the database, I don't believe Tuxedo will perform a one-phase commit, even if the two groups are connected to the same RM.
Regards,
Todd Little
Oracle Tuxedo Chief Architect

ADF Service Interface: two-phase commit issue for multiple data sources

In FusionApps, For a service interface we had to use two DataSource resources (in the ejb-jar.xml),
one is ApplicationServiceDBDS for SI and the other one is ApplicationDBDS(I don’t know the exact reason why this is needed, but when running the webservice, Framework was throwing an error asking for this) After adding these two, now(while running the webservice) we’re caught up with an error saying that unable to participate in two phase commit. I think this is because we added two dataSources, if we just use one dataSource everything is working fine.
Error message from app server:
"JDBC driver does not support XA, hence cannot be a participant in two-phase commit. To force this participation, set the GlobalTransactionsProtocol attribute to LoggingLastResource (recommended) or EmulateTwoPhaseCommit for the Data Source=ApplicationDB"
we have made the changes to ApplicationDB as said in the error message, but then the server is failing to start because of this.

Hi,
this is what the doc says - though not about two phase commit but transaction sharing:
"At runtime, the calling client and the ADF service may or may not participate in the same transaction, depending on the protocol used to invoke the service (either SOAP or RMI). Only the RMI protocol and a Java Transaction API (JTA) managed transaction support the option to call the service in the same transaction as the calling client."
When your application accesses a remote ADF Business Components service, each remote call is stateless, and the remote service will not participate in the same transaction as the business component that uses a service-enabled application module's service interface.
In the majority of the cases, calls to remote services will be informational in nature and will not make changes to remote objects. However, if you must use a remote service to make changes, then keep these points in mind:
An exception thrown by the remote service will cause the local transaction to fail.
If you successfully call a remote service that results in modifying data, and then subsequently your local transaction fails for any reason, then it is the responsibility of your error handling code to perform a compensating transaction against the remote service to "undo" the previous change made."
http://docs.oracle.com/cd/E23943_01/web.1111/b31974/bcextservices.htm
Frank

Two phase commit and bean managed transactions

To all the Transaction GURUS!
          Hi guys (-and gals).
          I've been doing J2EE for quite a while, but today was my first at
          XA-Transactions and Bean Managed Transactions.
          Why am I doing this?
          ====================
          Well I have to be able to controll the transactionalbehaviour of my
          bean
          during runtime, since some bean calls would cause a transactional
          overflow due to the stress they would cause to the system, whereas
          smaller bean calls need to run in one transaction.
          -> Therefore I need Bean Managed Transactions
          Since the bean does a call on two Database Connections it has to use a
          XA-Transaction.
          -> Therefore I need XA-Transactions.
          Abstract
          ========
          - I just can't get a User TransAction into the right Status it stays
          in 'STATUS_NO_TRANSACTION' all the time
          - Therefore the SQL Commands can be comitted 'java.sql.SQLException:
          Does not support SQL execution with no global transaction'
          - Therefore I can't do a rollback 'java.lang.IllegalStateException:
          Transaction does not exist'
          - Therefore I wrote this mail.
          I don't want to be a smart-"ass" writing such a detailed and indepth
          mail. I just would like to show that I tried, and would like to have
          some replies from you guys.
          Below are my configurations, code and logfiles.
          Thanx for taking your time and hope that the other people may learn
          something as well.
          cu
          Stefan
          Scenario
          ========
          used Software
          Bea Weblogic (WL) 6.0 SPx (not real sure which SP i have)
          Oracle 8.1.6 using the API-Version 8
          I configured the system as follows:
          (ofcourse I 'xxx'ed out all of the confidential data, sorry guys;-))
          excerpt from:
          config.xml
          <JDBCConnectionPool CapacityIncrement="5"
          DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="2"
          LoginDelaySeconds="1" MaxCapacity="5" Name="oraclePool"
          Properties="user=xxx;password=xxx;dll=ocijdbc8;protocol=thin"
          RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          TestTableName="languages" URL="jdbc:oracle:thin:@xxx:1521:xxx "/>
          
          <JDBCTxDataSource EnableTwoPhaseCommit="true"
          JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
          PoolName="oraclePool" Targets="fbsserver"/>
          
          <JDBCConnectionPool CapacityIncrement="5"
          DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
          LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
          Properties="user=xxx;password=xxx;server=xxx.xxx.xxx"
          RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          TestTableName="Users" SupportsLocalTransaction="true"/>
          
          <JDBCTxDataSource EnableTwoPhaseCommit="true"
          JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
          Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
          
          ejb-jar.xml
          <ejb-jar>
               <enterprise-beans>
                    <session>
                         <ejb-name>TPCTestBean</ejb-name>
          <home>de.sitewaerts.futuna.common.test.tpcbean.TPCHome</home>
          <remote>de.sitewaerts.futuna.common.test.tpcbean.TPC</remote>
          <ejb-class>de.sitewaerts.futuna.common.test.tpcbean.TPCBean</ejb-class>
                         <session-type>Stateless</session-type>
                         <transaction-type>Bean</transaction-type>
                    </session>
               </enterprise-beans>
               <assembly-descriptor/>
          </ejb-jar>
          
          weblogic-ejb-jar.xml
          <weblogic-ejb-jar>
               <weblogic-enterprise-bean>
                    <ejb-name>TPCTestBean</ejb-name>
                    <stateless-session-descriptor/>
                    <jndi-name>finstral/ejb/test_tpc</jndi-name>
               </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          
          BeanCode (from the implementingBeanClass:
          'de.sitewaerts.futuna.common.test.tpcbean.TPCBean')
          public void setupTables() throws RemoteException
          UserTransaction tx = getTransaction();
          //getTransaction calls: 'tx = sCtx.getUserTransaction()' and does
          some errorhandling
          log.info("Die Transaktion vor den Connections: "+tx.toString());
          //Sorry bout the German. You should get the Message though.
          log.info("Der Transaktionsstatus vor den Connections:
          "+transactionStatus(tx));
          Connection conSecurity = getConnection(DATASOURCE_SECURITY, tx);
          //gets a Connection via a DataSourceName from the JNDI tree
          Connection conContent = getConnection(DATASOURCE_CONTENT, tx);
          log.info("Die frische Connection conSecurity: "+conSecurity);
          log.info("Die frische Connection conContent: "+conContent);
          tearDownTable(conSecurity);
          //Does nothing special
          tearDownTable(conContent);
          log.info("Die Transaktion nach dem Teardown: "+tx.toString());
          log.info("Der Transaktionsstatus nach dem Teardown:
          "+transactionStatus(tx));
          Statement stmt = null;
          try
          stmt = conSecurity.createStatement();
          //Well its getting interesting now.....
          log.info("Die Transaktion vor dem createtable: "+tx.toString());
          log.info("Der Transaktionsstatus vor dem createtable:
          "+transactionStatus(tx));
          log.info("Die Connection conSecurity vor dem createtable:
          "+conSecurity);
          log.info("Die Connection conContent vor dem createtable:
          "+conContent);
          stmt.executeUpdate(CREATE_TABLE);
          //above is the row 91 -> throws: 'java.sql.SQLException: Does
          not support SQL execution with no global transaction'
          stmt.close();
          stmt = conContent.createStatement();
          stmt.executeUpdate(CREATE_TABLE);
          stmt.close();
          commitTransaction(tx);
          catch (SQLException sqle)
          log.error("Konnte kein table init machen", sqle);
          rollbackTransaction(tx);
          //The Code for this method is below
          throw new EJBException(sqle);
          finally
          closeConnection(conSecurity);
          closeConnection(conContent);
          protected void rollbackTransaction(UserTransaction tx)
          log.info("Der Transaktionsstatus vor dem Rollback:
          "+transactionStatus(tx));
          log.info("Die Transaktion vor dem Rollback: "+tx.toString());
          try
          tx.rollback();
          //above is row 200 -> throws: 'java.lang.IllegalStateException:
          Transaction does not exist'
          log.info("Der Transaktionsstatus nach dem Rollback:
          "+transactionStatus(tx));
          log.info("Die Transaktion nach dem Rollback: "+tx.toString());
          catch (Exception e)
          log.error("Konnte die Transaktion nicht backrollen.", e);
          throw new EJBException(e);
          Log Excerpt
          ===========
          INFO setupTables() (66) - Die Transaktion vor den Connections:
          [email protected]
          INFO setupTables() (67) - Der Transaktionsstatus vor den Connections:
          STATUS_NO_TRANSACTION
          INFO setupTables() (72) - Die frische Connection conSecurity:
          weblogic.jdbc.rmi.SerialConnection@7c6daa
          INFO setupTables() (73) - Die frische Connection conContent:
          weblogic.jdbc.rmi.SerialConnection@3b425
          INFO setupTables() (78) - Die Transaktion nach dem Teardown:
          [email protected]
          INFO setupTables() (79) - Der Transaktionsstatus nach dem Teardown:
          STATUS_NO_TRANSACTION
          INFO setupTables() (86) - Die Transaktion vor dem createtable:
          [email protected]
          INFO setupTables() (87) - Der Transaktionsstatus vor dem createtable:
          STATUS_NO_TRANSACTION
          INFO setupTables() (88) - Die Connection conSecurity vor dem
          createtable: weblogic.jdbc.rmi.SerialConnection@7c6daa
          INFO setupTables() (89) - Die Connection conContent vor dem
          createtable: weblogic.jdbc.rmi.SerialConnection@3b425
          ERROR setupTables() (101) - Konnte kein table init machen
          java.sql.SQLException: Does not support SQL execution with no global
          transaction
               at
          weblogic.jdbc.oci.xa.XAConnection.beforeExecute(XAConnection.java:137)
               at
          weblogic.jdbc.oci.xa.Statement.executeUpdate(Statement.java:112)
               at weblogic.jdbc.jta.Statement.executeUpdate(Statement.java:185)
               at
          weblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.jav
          a:42)
               at
          weblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:54)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.jav
          a:91)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBean
          Impl.java:130)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCBe
          anEOImpl.java:64)
               at
          de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseCo
          mmitUnitTest.java:51)
               at
          org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTes
          tCase.java:297)
               at
          org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servle
          tTestCaller.java:148)
               at
          org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCal
          ler.java:199)
               at
          org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTes
          tRedirector.java:149)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
               at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
          java:213)
               at
          weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl
          etContext.java:1265)
               at
          weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.
          java:1631)
               at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
               at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          INFO rollbackTransaction() (196) - Der Transaktionsstatus vor dem
          Rollback: STATUS_NO_TRANSACTION
          INFO rollbackTransaction() (197) - Die Transaktion vor dem Rollback:
          [email protected]
          ERROR rollbackTransaction() (206) - Konnte die Transaktion nicht
          backrollen.
          java.lang.IllegalStateException: Transaction does not exist
               at
          weblogic.transaction.internal.TransactionManagerImpl.rollback(Transactio
          nManagerImpl.java:228)
               at
          weblogic.transaction.internal.TransactionManagerImpl.rollback(Transactio
          nManagerImpl.java:222)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBean.rollbackTransaction(TPC
          Bean.java:200)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.jav
          a:102)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBean
          Impl.java:130)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCBe
          anEOImpl.java:64)
               at
          de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseCo
          mmitUnitTest.java:51)
               at
          org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTes
          tCase.java:297)
               at
          org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servle
          tTestCaller.java:148)
               at
          org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCal
          ler.java:199)
               at
          org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTes
          tRedirector.java:149)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
               at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
          java:213)
               at
          weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl
          etContext.java:1265)
               at
          weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.
          java:1631)
               at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
               at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          CONCLUSION
          ==========
          I'm going nuts.
          I just don't get it.
          The transaction is the same. I don't change the Connection. I start
          the Transaction at the beginning before I do anything!
          Please guys help me out.
          Thx alot.
          Stefan "it's three o'clock in the morning, my girlfriend left me, and
          my only friend is that stupid linux pinguine" Siprell
          Software-Development
          <<<<<<<<<<<<<<<<<<<<<<<<<<<
          <sitewaerts> GmbH
          Hebelstraße 15
          D-76131 Karlsruhe
          Tel: +49 (721) 920 918 22
          Fax: +49 (721) 920 918 29
          http://www.sitewaerts.de
          >>>>>>>>>>>>>>>>>>>>>>>>>>>


Hi Priscilla
          (did you ever see the movie ? :-))
          Well I moved away from the idea of using bean managed transaction. I'll
          be using Container Managed Transactions. To modify the
          transactionalbehaviour I'll write proxymethods which have certain
          different containermanaged transaction properties, but which all call
          the same private methods.
          But it works! Here is my experience:
          - I was doing a DDL statement: I was trying to create new Tables, which
          is a definite "no-go"
          - pay careful attention to:
          http://edocs.bea.com/wls/docs60/jta/trxejb.html#1051405
                    and
          http://edocs.bea.com/wls/docs60/jta/trxejb.html#1051741
          and use these Settings for the Pool, don't ask me why, but it took me
          hours to find it out by myself:
               <JDBCConnectionPool CapacityIncrement="5"
          DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
          LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
          Properties="user=xxx; password=xxx; server=xxx.xxx.xxx"
          RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          TestTableName="Users" SupportsLocalTransaction="true"/>
          where as the server (shown as: xxx.xxx.xxx) is the TNS Name of the
          Oracle Driver.
          It works great.
          Another thing you guys might want to do is write a simple StatelessSB
          which does JDBC calls and two different database Connections.
          Then write a UnitTest which calls this bean a couple hundred times (with
          the same transaction). Have one test do clean writes, and another which
          causes some SQL-Exception (too long Data Columns, or likewise).
          Always count the entries and see if everything worked out. We're using
          this SetupConstruction to test new combinations of AS(sorry Priscilla) /
          Database / Db-Drivers to have a "standard test".
          I know my two cents were uncalled for, but it might save you some
          time.....
          thanx for your help
          Stefan
          -----Ursprüngliche Nachricht-----
          Von: Priscilla Fung [mailto:[email protected]]
          Bereitgestellt: Donnerstag, 2. August 2001 21:42
          Bereitgestellt in: transaction
          Unterhaltung: Two phase commit and bean managed transactions
          Betreff: Re: Two phase commit and bean managed transactions
          Hi Stefan,
          Looks like you have not actually begun a transaction by calling
          UserTransaction.begin(),
          so your setupTables method is really executing with no transaction
          context.
          Priscilla
          Stefan Siprell <[email protected]> wrote:
          >To all the Transaction GURUS!
          >
          >Hi guys (-and gals).
          >I've been doing J2EE for quite a while, but today was my first at
          >XA-Transactions and Bean Managed Transactions.
          >
          >Why am I doing this?
          >====================
          >Well I have to be able to controll the transactionalbehaviour of my
          >bean
          >during runtime, since some bean calls would cause a transactional
          >overflow due to the stress they would cause to the system, whereas
          >smaller bean calls need to run in one transaction.
          >-> Therefore I need Bean Managed Transactions
          >Since the bean does a call on two Database Connections it has to use
          >a
          >XA-Transaction.
          >-> Therefore I need XA-Transactions.
          >
          >Abstract
          >========
          >- I just can't get a User TransAction into the right Status it stays
          >in 'STATUS_NO_TRANSACTION' all the time
          >- Therefore the SQL Commands can be comitted 'java.sql.SQLException:
          >Does not support SQL execution with no global transaction'
          >- Therefore I can't do a rollback 'java.lang.IllegalStateException:
          >Transaction does not exist'
          >- Therefore I wrote this mail.
          >
          >I don't want to be a smart-"ass" writing such a detailed and indepth
          >mail. I just would like to show that I tried, and would like to have
          >some replies from you guys.
          >
          >Below are my configurations, code and logfiles.
          >
          >Thanx for taking your time and hope that the other people may learn
          >something as well.
          >
          >cu
          >
          >Stefan
          >
          >
          >Scenario
          >========
          >
          >used Software
          >-------------
          >Bea Weblogic (WL) 6.0 SPx (not real sure which SP i have)
          >Oracle 8.1.6 using the API-Version 8
          >
          >
          >I configured the system as follows:
          >(ofcourse I 'xxx'ed out all of the confidential data, sorry guys;-))
          >excerpt from:
          >
          >config.xml
          >----------
          ><JDBCConnectionPool CapacityIncrement="5"
          >DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="2"
          >LoginDelaySeconds="1" MaxCapacity="5" Name="oraclePool"
          >Properties="user=xxx;password=xxx;dll=ocijdbc8;protocol=thin"
          >RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          >TestTableName="languages" URL="jdbc:oracle:thin:@xxx:1521:xxx "/>
          >
          >
          >
          ><JDBCTxDataSource EnableTwoPhaseCommit="true"
          >JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
          >PoolName="oraclePool" Targets="fbsserver"/>
          >
          >
          >
          ><JDBCConnectionPool CapacityIncrement="5"
          >DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
          >LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
          >Properties="user=xxx;password=xxx;server=xxx.xxx.xxx"
          >RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          >TestTableName="Users" SupportsLocalTransaction="true"/>
          >
          >
          >
          ><JDBCTxDataSource EnableTwoPhaseCommit="true"
          >JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
          >Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
          >
          >
          >
          >
          >
          >ejb-jar.xml
          >-----------
          ><ejb-jar>
          >     <enterprise-beans>
          >          <session>
          >               <ejb-name>TPCTestBean</ejb-name>
          >
          ><home>de.sitewaerts.futuna.common.test.tpcbean.TPCHome</home>
          >
          ><remote>de.sitewaerts.futuna.common.test.tpcbean.TPC</remote>
          >
          ><ejb-class>de.sitewaerts.futuna.common.test.tpcbean.TPCBean</ejb-class>
          >               <session-type>Stateless</session-type>
          >               <transaction-type>Bean</transaction-type>
          >          </session>
          >     </enterprise-beans>
          >     <assembly-descriptor/>
          ></ejb-jar>
          >
          >
          >
          >weblogic-ejb-jar.xml
          >--------------------
          ><weblogic-ejb-jar>
          >     <weblogic-enterprise-bean>
          >          <ejb-name>TPCTestBean</ejb-name>
          >          <stateless-session-descriptor/>
          >          <jndi-name>finstral/ejb/test_tpc</jndi-name>
          >     </weblogic-enterprise-bean>
          ></weblogic-ejb-jar>
          >
          >
          >
          >BeanCode (from the implementingBeanClass:
          >'de.sitewaerts.futuna.common.test.tpcbean.TPCBean')
          >-----------------------------------------------------------------------
          >---------------------
          >
          > public void setupTables() throws RemoteException
          > {
          > UserTransaction tx = getTransaction();
          > //getTransaction calls: 'tx = sCtx.getUserTransaction()' and does
          >some errorhandling
          >
          > log.info("Die Transaktion vor den Connections: "+tx.toString());
          > //Sorry bout the German. You should get the Message though.
          > log.info("Der Transaktionsstatus vor den Connections:
          >"+transactionStatus(tx));
          >
          > Connection conSecurity = getConnection(DATASOURCE_SECURITY, tx);
          > //gets a Connection via a DataSourceName from the JNDI tree
          > Connection conContent = getConnection(DATASOURCE_CONTENT, tx);
          >
          > log.info("Die frische Connection conSecurity: "+conSecurity);
          > log.info("Die frische Connection conContent: "+conContent);
          >
          > tearDownTable(conSecurity);
          > //Does nothing special
          > tearDownTable(conContent);
          >
          > log.info("Die Transaktion nach dem Teardown: "+tx.toString());
          > log.info("Der Transaktionsstatus nach dem Teardown:
          >"+transactionStatus(tx));
          >
          > Statement stmt = null;
          > try
          > {
          > stmt = conSecurity.createStatement();
          > //Well its getting interesting now.....
          >
          > log.info("Die Transaktion vor dem createtable: "+tx.toString());
          > log.info("Der Transaktionsstatus vor dem createtable:
          >"+transactionStatus(tx));
          > log.info("Die Connection conSecurity vor dem createtable:
          >"+conSecurity);
          > log.info("Die Connection conContent vor dem createtable:
          >"+conContent);
          >
          > stmt.executeUpdate(CREATE_TABLE);
          > //above is the row 91 -> throws: 'java.sql.SQLException: Does
          >not support SQL execution with no global transaction'
          >
          > stmt.close();
          >
          > stmt = conContent.createStatement();
          > stmt.executeUpdate(CREATE_TABLE);
          > stmt.close();
          > commitTransaction(tx);
          > }
          > catch (SQLException sqle)
          > {
          > log.error("Konnte kein table init machen", sqle);
          > rollbackTransaction(tx);
          > //The Code for this method is below
          > throw new EJBException(sqle);
          > }
          > finally
          > {
          > closeConnection(conSecurity);
          > closeConnection(conContent);
          > }
          > }
          >
          > protected void rollbackTransaction(UserTransaction tx)
          > {
          > log.info("Der Transaktionsstatus vor dem Rollback:
          >"+transactionStatus(tx));
          > log.info("Die Transaktion vor dem Rollback: "+tx.toString());
          > try
          > {
          > tx.rollback();
          > //above is row 200 -> throws: 'java.lang.IllegalStateException:
          >Transaction does not exist'
          > log.info("Der Transaktionsstatus nach dem Rollback:
          >"+transactionStatus(tx));
          > log.info("Die Transaktion nach dem Rollback: "+tx.toString());
          > }
          > catch (Exception e)
          > {
          > log.error("Konnte die Transaktion nicht backrollen.", e);
          > throw new EJBException(e);
          > }
          > }
          >
          >Log Excerpt
          >===========
          >INFO setupTables() (66) - Die Transaktion vor den Connections:
          >[email protected]
          >INFO setupTables() (67) - Der Transaktionsstatus vor den Connections:
          >STATUS_NO_TRANSACTION
          >INFO setupTables() (72) - Die frische Connection conSecurity:
          >weblogic.jdbc.rmi.SerialConnection@7c6daa
          >INFO setupTables() (73) - Die frische Connection conContent:
          >weblogic.jdbc.rmi.SerialConnection@3b425
          >INFO setupTables() (78) - Die Transaktion nach dem Teardown:
          >[email protected]
          >INFO setupTables() (79) - Der Transaktionsstatus nach dem Teardown:
          >STATUS_NO_TRANSACTION
          >INFO setupTables() (86) - Die Transaktion vor dem createtable:
          >[email protected]
          >INFO setupTables() (87) - Der Transaktionsstatus vor dem createtable:
          >STATUS_NO_TRANSACTION
          >INFO setupTables() (88) - Die Connection conSecurity vor dem
          >createtable: weblogic.jdbc.rmi.SerialConnection@7c6daa
          >INFO setupTables() (89) - Die Connection conContent vor dem
          >createtable: weblogic.jdbc.rmi.SerialConnection@3b425
          >ERROR setupTables() (101) - Konnte kein table init machen
          >java.sql.SQLException: Does not support SQL execution with no global
          >transaction
          >     at
          >weblogic.jdbc.oci.xa.XAConnection.beforeExecute(XAConnection.java:137)
          >     at
          >weblogic.jdbc.oci.xa.Statement.executeUpdate(Statement.java:112)
          >     at weblogic.jdbc.jta.Statement.executeUpdate(Statement.java:185)
          >     at
          >weblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.ja
          v
          >a:42)
          >     at
          >weblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:54
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.ja
          v
          >a:91)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBea
          n
          >Impl.java:130)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCB
          e
          >anEOImpl.java:64)
          >     at
          >de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseC
          o
          >mmitUnitTest.java:51)
          >     at
          >org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTe
          s
          >tCase.java:297)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servl
          e
          >tTestCaller.java:148)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCa
          l
          >ler.java:199)
          >     at
          >org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTe
          s
          >tRedirector.java:149)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          >     at
          >weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl
          >java:213)
          >     at
          >weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServ
          l
          >etContext.java:1265)
          >     at
          >weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl
          >java:1631)
          >     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
          >     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          >INFO rollbackTransaction() (196) - Der Transaktionsstatus vor dem
          >Rollback: STATUS_NO_TRANSACTION
          >INFO rollbackTransaction() (197) - Die Transaktion vor dem Rollback:
          >[email protected]
          >ERROR rollbackTransaction() (206) - Konnte die Transaktion nicht
          >backrollen.
          >java.lang.IllegalStateException: Transaction does not exist
          >     at
          >weblogic.transaction.internal.TransactionManagerImpl.rollback(Transacti
          o
          >nManagerImpl.java:228)
          >     at
          >weblogic.transaction.internal.TransactionManagerImpl.rollback(Transacti
          o
          >nManagerImpl.java:222)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.rollbackTransaction(TP
          C
          >Bean.java:200)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.ja
          v
          >a:102)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBea
          n
          >Impl.java:130)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCB
          e
          >anEOImpl.java:64)
          >     at
          >de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseC
          o
          >mmitUnitTest.java:51)
          >     at
          >org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTe
          s
          >tCase.java:297)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servl
          e
          >tTestCaller.java:148)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCa
          l
          >ler.java:199)
          >     at
          >org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTe
          s
          >tRedirector.java:149)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          >     at
          >weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl
          >java:213)
          >     at
          >weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServ
          l
          >etContext.java:1265)
          >     at
          >weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl
          >java:1631)
          >     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
          >     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          >
          >
          >CONCLUSION
          >==========
          >I'm going nuts.
          >I just don't get it.
          >The transaction is the same. I don't change the Connection. I start
          >the Transaction at the beginning before I do anything!
          >Please guys help me out.
          >Thx alot.
          >
          >Stefan "it's three o'clock in the morning, my girlfriend left me, and
          >my only friend is that stupid linux pinguine" Siprell
          >Software-Development
          ><<<<<<<<<<<<<<<<<<<<<<<<<<<
          ><sitewaerts> GmbH
          >Hebelstraße 15
          >D-76131 Karlsruhe
          >
          >Tel: +49 (721) 920 918 22
          >Fax: +49 (721) 920 918 29
          >http://www.sitewaerts.de
          >>>>>>>>>>>>>>>>>>>>>>>>>>>>
          >
          >
          >

The method 'commit' cant be called when a global transaction is active.

Hello,
I've installed the SOAdemo a couple of times on local machines, and it works fine. Now I've deployed the SOADemo on a separate server and a strange error occurs in BPEL when testing the SOADemo.
The SOAOrderBooking BPEL process runs into an error at the GetOrderId process:
================================
file:/C:/product/10.1.3.1/OracleAS_1/bpel/domains/default/tmp/.bpel_SOAOrderBooking_1.0_937b09d1bd8dae1b33b028b2871aef63.tmp/OrderSequence.wsdl [ OrderSequence_ptt::OrderSequence(OrderSequenceInput_msg,OrderSequenceOutputCollection) ] - WSIF JCA Execute of operation 'OrderSequence' failed due to: DBWriteInteractionSpec Execute Failed Exception.
unknown failed. Descriptor name: [unknown]. [Caused by: The method 'commit' cant be called when a global transaction is active .
; nested exception is:
     ORABPEL-11616
=================================
I am using SOA Suite 10.1.3.0 and Database 10201, deployed on Windows.
Can anybody tell me what can cause this problem?
Thanks in advance,
Regards Leon

Hi,
Hi, I am getting the same error using ESB Database Adapter.
My faultstring is:
========================
oracle.tip.esb.server.common.exceptions.BusinessEventRetriableException: An unhandled exception has been thrown in the ESB system. The exception reported is: "oracle.tip.esb.server.common.exceptions.BusinessEventRetriableException: An unhandled exception has been thrown in the ESB system. The exception reported is: "org.collaxa.thirdparty.apache.wsif.WSIFException: esb:///ESB_Projects/my_ESB/myAdapter.wsdl [ myAdapter_ptt::myAdapter(InputParameters,OutputParameters) ] - WSIF JCA Execute of operation 'myAdapter' failed due to: DBWriteInteractionSpec Execute Failed Exception.
unknown failed. Descriptor name: [unknown]. [Caused by: The method 'commit' cant be called when a global transaction is active.]
; nested exception is:
     ORABPEL-11616
DBWriteInteractionSpec Execute Failed Exception.
unknown failed. Descriptor name: [unknown]. [Caused by: The method 'commit' cant be called when a global transaction is active.]
Caused by Exceptoin [TOPLINK-4002] (Oracle TopLink - 10g Release 3 (10.1.3.1.0) (Build 061004)): oracle.toplink.exceptions.DatabaseException
Belső kivétel: java.sql.SQLException: The method 'commit' cant be called when a global transaction is active.Error Code: 0.
==========================
(BTW, what has 'commit' to do with a procedure that is only reading the database?)
Regards,
Patrik

Distributed transactions and 2-phase commit in a SAP Netweaver environment

Hello,
I am a Java architect., I don't know very much the SAP technologies. I tried to found on forums or technical papers if SAP does support distributed transactions and two-phase commit, it's not clear. I found something on SAP WAS but my project is using a SAP PI 7.0 and I cannot find anything on the subject.
My goal is to include a SAP server (via PI 7.0) in a distributed transaction handled by a J2EE ESB (Oracle, ex-BEA Aqualogic) based on XA capabilities.
Does anyone have experience or feedback on this topic ?
Thanks.

Hi,
Do you know this white paper ?
[Distributed Transaction and 2 phase commit|https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/3732d690-0201-0010-a993-b92aab79701f]
Regards,
Olivier

Could not turn on auto-commit in an active global transaction

Why and when does toplink throw this exception
09/09/28 17:50:58 Caused by: java.sql.SQLException: could not turn on auto-commit in an active global transaction
09/09/28 17:50:58 at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
09/09/28 17:50:58 at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
09/09/28 17:50:58 at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:208)
09/09/28 17:50:58 at oracle.jdbc.driver.PhysicalConnection.disallowGlobalTxnMode(PhysicalConnection.java:4045)
09/09/28 17:50:58 at oracle.jdbc.driver.PhysicalConnection.setAutoCommit(PhysicalConnection.java:1343)
09/09/28 17:50:58 at oracle.jdbc.OracleConnectionWrapper.setAutoCommit(OracleConnectionWrapper.java:107)
09/09/28 17:50:58 at oracle.oc4j.sql.spi.ManagedConnectionImpl.setAutoCommit(ManagedConnectionImpl.java:572)
09/09/28 17:50:58 at oracle.oc4j.sql.spi.ManagedConnectionImpl.initForUse(ManagedConnectionImpl.java:167)
09/09/28 17:50:58 at oracle.oc4j.sql.spi.ManagedConnectionImpl.<init>(ManagedConnectionImpl.java:106)
09/09/28 17:50:58 at oracle.oc4j.sql.spi.ManagedConnectionFactoryImpl.createManagedConnection(ManagedConnectionFactoryImpl.java:171)
09/09/28 17:50:58 at com.evermind.server.connector.ApplicationConnectionManager.createManagedConnection(ApplicationConnectionManager.java:1398)
09/09/28 17:50:58 at oracle.j2ee.connector.ConnectionPoolImpl.createManagedConnectionFromFactory(ConnectionPoolImpl.java:327)
09/09/28 17:50:58 at oracle.j2ee.connector.ConnectionPoolImpl.access$800(ConnectionPoolImpl.java:98)
09/09/28 17:50:58 at oracle.j2ee.connector.ConnectionPoolImpl$NonePoolingScheme.getManagedConnection(ConnectionPoolImpl.java:1211)
09/09/28 17:50:58 at oracle.j2ee.connector.ConnectionPoolImpl.getManagedConnection(ConnectionPoolImpl.java:785)
09/09/28 17:50:58 at oracle.oc4j.sql.ConnectionPoolImpl.getManagedConnection(ConnectionPoolImpl.java:45)
09/09/28 17:50:58 at com.evermind.server.connector.ApplicationConnectionManager.getConnectionFromPool(ApplicationConnectionManager.java:1596)
09/09/28 17:50:58 at com.evermind.server.connector.ApplicationConnectionManager.acquireConnectionContext(ApplicationConnectionManager.java:1541)
09/09/28 17:50:58 at com.evermind.server.connector.ApplicationConnectionManager.allocateConnection(ApplicationConnectionManager.java:1486)
09/09/28 17:50:58 at oracle.j2ee.connector.OracleConnectionManager.unprivileged_allocateConnection(OracleConnectionManager.java:238)
09/09/28 17:50:58 at oracle.j2ee.connector.OracleConnectionManager.allocateConnection(OracleConnectionManager.java:192)
09/09/28 17:50:58 at oracle.oc4j.sql.ManagedDataSource.getConnection(ManagedDataSource.java:272)
09/09/28 17:50:58 at oracle.oc4j.sql.ManagedDataSource.getConnection(ManagedDataSource.java:200)
09/09/28 17:50:58 at oracle.oc4j.sql.ManagedDataSource.getConnection(ManagedDataSource.java:142)
09/09/28 17:50:58 at oracle.oc4j.sql.ManagedDataSource.getConnection(ManagedDataSource.java:127)
09/09/28 17:50:58 at oracle.toplink.essentials.jndi.JNDIConnector.connect(JNDIConnector.java:145)
Thanks,
ND

Hello,
As you can tell from the stack trace, TopLink is not throwing the exception, the connection is when TopLink is attempting to get a connection from the datasource. getConnection should not be throwing this exception, so it is likely a datasource configuration issue or a problem in the driver you are using. How is the datasource configured, what is the version of Oc4J and the driver you are using, and can you try using a different driver version?
Best Regards,
Chris

Advise on using DBMS_XA with multiple branches under one global transaction

Dear all
I need some advise on using DBMS_XA from PL/SQL with tightly coupled multiple branches under one global transaction. Basically, I've successfully written some PL/SQL code that in 3 different sessions attaches to 3 different branches of one global transaction and before ending each branch they can see each others uncommitted data. So far so good.
However, I'm not sure I completely understand how each branch must call xa_end, xa_prepare and xa_commit correctly using two phase commit and my calls result in errors like:
ORA-24767: transaction branch prepare returns read-only (XA error code 3 = Transaction was read-only and has been committed)
ORA-24756: transaction does not exist (XA error code -4 = XID is not valid)
ORA-02051: another session or branch in same transaction failed or finalized
This is the structure of my programs (3 SQL*Plus sessions):
main: Uses xid 123|0 (branch 0 of global transaction 123). This should be the coordinator that commits using two phase commit across the 3 branches
m1.xa_start tmnoflags
m2.DML
m3.Wait for thread A + B to manually be started and run xa_end
m4.xa_end tmsuccess
m5.xa_prepare
m6.xa_commit false
thread A: Uses xid 123|A (branch A of global transaction 123)
a1.xa_start tmnoflags
a2.DML -- thread A can see main and thread B's data
a3.xa_end tmsuccess
a4.xa_prepare -- required?
a5.Should we also call xa_commit false?
thread B: Uses xid 123|B (branch B of global transaction 123)
b1.xa_start tmnoflags
b2.DML -- thread B can see main and thread A's data
b3.xa_end tmsuccess
b4.xa_prepare -- required?
b5.Should we also call xa_commit false?
The failing steps are:
m5
m6
a4
a5
b4
b5
Before starting calling xa_end I see 3 rows in V$GLOBAL_TRANSACTION, eg (hex 7B = decimal 123):
FORMATID GLOBALID BRANCHID BRANCHES REFCOUNT PREPARECOUNT STATE FLAGS COUPLING
203348753 0000007B 00000000000000000000000000000000 3 3 0 ACTIVE 0 TIGHTLY COUPLED
203348753 0000007B 0000000000000000000000000000000A 3 3 0 ACTIVE 0 TIGHTLY COUPLED
203348753 0000007B 0000000000000000000000000000000B 3 3 0 ACTIVE 0 TIGHTLY COUPLED
Thanks a lot in advance.
Cheers
Finn

OK, I've figured it out. This is poorly documented as it's not well explained how to handle the various return codes. Turns out that all but the last xa_prepare calls return dbms_xa.xa_rdonly (tightly coupled branches are combined -- "read only" optimization), the last one returns dbms_xa.xa_ok and this is when you should call xa_commit.
Now my next problem is that DBMS_XA doesn't work from within jobs (DBMS_JOB and DBMS_SCHEDULER), which makes it very difficult to use DBMS_XA. My purpose of using DBMS_XA is to coordinate work across multiple sessions in one transaction but if I can't easily create the multiple sessions, I'm stuck.
When called from a job, xa_start throws:
ORA-24789: start not allowed in recursive call
on Oracle 11.2. In Oracle 11.1 it works, but xa_end fails with
ORA-25352: no current transaction
so I guess in fact the xa_start call didn't really work either, even though it returned tm_ok.
I'm now trying to find a workaround on how to use DBMS_XA from within jobs, please comment if you have any suggestions. Or if you have any suggestions on other means of establishing the concurrent sessions (I wouldn't like to resort to external programs that need username/password to connect as password management would be a security issue).
Thanks in advance.
Cheers
Finn

Configuration of two-phase-commit in OC4J 10.1.2

Configuration of two-phase-commit in OC4J 10.1.2 in application with multiple modules
We have an application ear file consisting of ejb-modules (mdb and slsb) and two web-modules. We are using Oracle's advanced queueing for messaging and CMT (all ejb use the Required transaction attribute). We need different datasources (OrionCMTDataSource) including that for aq, so we need two-phase-commit. The web clients use ejbs and browse the messaging system. Our 'orion-application.xml' includes a commit-coordinator configuration, and the database is setup correctly. The configuration works fine for mdbs, when sending messages to the queues. When a client starts after messages have been sent and consumed by the mdbs, oc4j complains that no commit-coordinator is defined in 'server.xml'. If we start the client first, it can access the queues, but then the mdbs complain. It seems that the first one "gets" the commit-coordinator and the second one fails.
Some questions:
Why isn't the second client type using the commit-coordinator configuration of the "orion-application.xml"?
Is such scenario not supported by OC4J?
How can I setup the application correctly?
How do I configure commit-coordinator with different datasources to the same database? (Commit-Coordinator is also this database)

Take a look 'How to Use a Custom Serializer with Oracle Application Server Web Services' [1].
In your case, you should be looking at BeanMultiRefSerializer (org.apache.soap.encoding.soapenc), which will serialize your data using href and providing a way to deal with cycles.
All the best,
Eric
[1] http://www.oracle.com/technology/tech/webservices/htdocs/samples/serialize/index.html

Can the ApplicationModule support global Transaction for multi db instance?

purpose:
I want to update data in two db instance .
pre-conditions:
I create two application module , in the two application modules ,one is root application module. one application module connect one db instance, the other application module connect to the other db instance.The two application modules include entity objects and view objects which map the tables in the two db instance.
In the jsp page , I bind two view objects , one view is owned by root application module ,the other view object is owned by child application module and the two view objects map the two tables which are in different db instance .the view objects binding style in the jsp page is input-form.
The result:
while the input-form is submitted ,the error occurs.The global transaction isn't committed, why?

A nested application module instance uses the transaction/connection of its parent.
The simplest way to accomplish what you're trying to do is to use Oracle database DBLinks so that the two-phase commit is handled at the database level.
ADFBC does not support two-phase commit at the application level between two separate root application module's transactions.

Data-source.xml - BaseResourceException - two phase commit

Hi,
I am seeing the following exception.   Please let me know how to fix this.
thanks
Sunita
com.sap.engine.services.connector.exceptions.BaseResourceException: The resource "xxx" does not support two-phase commit and cannot be enlisted in the current transaction, because another non supporting two-phase commit resource is already enlisted for component "webContainer/applications/JavaEE/YY-TPRO/YYr-TPRO" in application "JavaEE/YY-TPRO". Only one of the enlisted resources is allowed to be non two-phase commit compliant.
I am using JDBC 1.x datasource, and the .xml looks like this:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE data-sources SYSTEM 'data-sources.dtd'>
<data-sources>
<application-name>JavaEE/yy-TPRO</application-name>
<data-source>
    <data-source-name>xxx</data-source-name>
    <alias>jdbc/xxyyDB/TPRO</alias>
    <driver-name>OracleThin</driver-name>
    <init-connections>1</init-connections>
    <max-connections>20</max-connections>
    <max-time-to-wait-connection>60</max-time-to-wait-connection>
    <sql-engine>vendor_sql</sql-engine>
    <jdbc-1.x>
      <driver-class-name>oracle.jdbc.driver.OracleDriver</driver-class-name>
      <url>jdbc:oracle:thin:@sol-mercury:1521:hermes</url>
      <user-name>abcd</user-name>
      <password>abcd</password>
    </jdbc-1.x>
</data-source>
</data-sources>

HI,
Thanks for the response, I already went through these threads.
My exception seems to be related to this - Problem with connection sharing if J2EE transaction is running
and suggested solutions seems to be:
The problem is caused when there is an inappropriate attempt to open a second connection in an active JTA transaction. There is either an attempt to get a second connection from an un-shareable non-XA DataSource or an attempt to get it from another non-XA DataSource. You have to:
●     Use no more than one connection from this data source while the JTA transaction is active or
●     Declare the data source as shareable, depending on your application logic.
Question is, How can I make data source as shareable??
This application worked fine in JBoss, weblogic and now we are trying to port it to NetWeaver.
Is any of the above options are configurable in data-sources.xml?
Thanks for your guidance and response.
Surekha

Operation Connection.rollback is not allowed during a global transaction.

Hi
I am getting the following exception when i try to deploy my application in the server. Is any body got the same error. please help me to solve this problem.
com.ibm.mm.beans.CMBException: DSRA9350E: Operation Connection.rollback is not allowed during a global transaction.
java.sql.SQLException: DSRA9350E: Operation Connection.rollback is not allowed during a global transaction.
     at com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.rollback(WSJdbcConnection.java:2270)
     at com.ibm.mm.sdk.internal.sql.PConnectionICM.rollback(PConnectionICM.java:230)
     at com.ibm.mm.sdk.server.DKDatastoreICM.connect(DKDatastoreICM.java:3273)
     at com.ibm.mm.beans.CMBConnection.connect(CMBConnection.java:1685)
Thanks.

Are you using an XA driver for two-phase commit?
%

2 Phase Commit Global Transaction resolution question.

Similar Messages

Maybe you are looking for