Releasing beans in transactions causes locktimedoutexception
Hello,
We are currently facing the problem of a lot of locktimedoutexceptions. In search of the possible origin I encountered that releasing the bean manually was probably causing the problem. I have now removed the call to the "remove()" method and my problem seems to have disappeared. Now my question is why does this happen. We are working with container managed transactions and I think we cannot call the remove method in a transaction.
Greetings Manuel
More info needed. Are you doing a remove on a session bean? Also, what is
the version of weblogic you are using.
"Manuel Moons" <[email protected]> wrote in message
news:3cbd24c2$[email protected]..
Hello,
We are currently facing the problem of a lot of locktimedoutexceptions.In search of the possible origin I encountered that releasing the bean
manually was probably causing the problem. I have now removed the call to
the "remove()" method and my problem seems to have disappeared. Now my
question is why does this happen. We are working with container managed
transactions and I think we cannot call the remove method in a transaction.
Greetings Manuel
Similar Messages
-
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 "/>
<!-- Since this is our Main Datasource I would not like to use a XA
Transaction due to performance Issues
and the TxDataSource:
-->
<JDBCTxDataSource EnableTwoPhaseCommit="true"
JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
PoolName="oraclePool" Targets="fbsserver"/>
<!-- no comment required -I hope.
Next comes the "special" Pool
-->
<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"/>
<!-- Well since there can only be one none XARessourceManager involved
in a 2PC
(keyword: Two Phase Commit) I will have to use a XACapable Driver for
the other
Datasource. Due to all the bugs in the oracle.xxx driver. I'll be
using the jdriver for oci.
I activated 'SupportsLocalTransaction' hoping it would solve my
problem - without effect. I just left in there now, since it made
sense me. Not?
Again the TxDataSource:
-->
<JDBCTxDataSource EnableTwoPhaseCommit="true"
JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
<!-- The System starts right up and can locate the test tables and
everything. So I think all of this stuff is working here -->
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>
<!-- Originally I had the assembly-descriptor full of transaction
requirements. I thought since
the bean is handling all of the transaction stuff itself, it might get
confused by the 'container-transaction'
properties, and deleted them. Do I need them anyway?-->
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>
<!-- Nothing I have to explain here -->
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 "/>
>
><!-- Since this is our Main Datasource I would not like to use a XA
>Transaction due to performance Issues
>and the TxDataSource:
>-->
>
><JDBCTxDataSource EnableTwoPhaseCommit="true"
>JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
>PoolName="oraclePool" Targets="fbsserver"/>
>
><!-- no comment required -I hope.
>Next comes the "special" Pool
>-->
>
><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"/>
>
><!-- Well since there can only be one none XARessourceManager involved
>in a 2PC
>(keyword: Two Phase Commit) I will have to use a XACapable Driver for
>the other
>Datasource. Due to all the bugs in the oracle.xxx driver. I'll be
>using the jdriver for oci.
>I activated 'SupportsLocalTransaction' hoping it would solve my
>problem - without effect. I just left in there now, since it made
>sense me. Not?
>Again the TxDataSource:
>-->
>
><JDBCTxDataSource EnableTwoPhaseCommit="true"
>JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
>Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
>
><!-- The System starts right up and can locate the test tables and
>everything. So I think all of this stuff is working here -->
>
>
>
>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>
>
><!-- Originally I had the assembly-descriptor full of transaction
>requirements. I thought since
>the bean is handling all of the transaction stuff itself, it might get
>confused by the 'container-transaction'
>properties, and deleted them. Do I need them anyway?-->
>
>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>
>
><!-- Nothing I have to explain here -->
>
>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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>
>
-
Error generating release against Scheduling agreement (Cause 2)
dear Sap Experts,
Please advise me that Error generating release against Scheduling agreement (Cause 2)
As i have already used transaction code OMQP and click print operation 9 for LPH1 & LPJI A,
How can i sort this problem.
Thanks
mohitHi,
pls find below thread
SA delivery schedule release problem
you have to Maintain condition records for LPJ1 and LPF1 in NACE
maintain condition record in transaction MN10 for schedule release. And Generally in the condition records will be maintained for LPH1 & LPJ1in MN10.
Once you maintain that, you can go to ME84 and ME38 release the schedule
the JIT indicator in MMR for your material.
Check that and also you can maintain a release creation profile in VMR or ME31L.
Regards
Raj. -
Bean-managed transaction with EJB 3.0
Hi,
I try to get a bean-managed transaction example running with EJB 3.0 under GlassFish v2ur2.
In order to demarcate the scenario I have to get me the UserTransaction which I get from the SessionContext. I would like to use it then like: UserTransaction ut = context.getUserTransaction();
I tried to get the SessionContext with the help of the EJB method setSessionContext which should be called by the container after instance creation.
However, setting a log output into that method does not show any call of this method.
So, how can I get this method called or is there another way to get the SessionContext for the UserTransaction to work ?
Are there any good and fully implemented examples for bean-managed transactions ?
Thanks for your help.
RegardsI found the solution for that my SessionContext was NULL and I could not use the UserTransaction.
The reason for it is that I injected the EJB with @EJB into my servlet and did a MyBean mybean = new MyBean();
That leads to a SessionContext which is NULL within my EJB.
If I use it without instantiating it it works fine.
Again, thanks for your help. At least it pointed me into the right direction.
Regards -
Error generating release against scheduling agreement (cause 6) in ME38
Hello Experts,
Need your inputs on the the below error getting generated in ME38
Error generating release against scheduling agreement (cause 6)
Message no. 06857
Diagnosis
The function module for generating a scheduling agreement release (forecast delivery schedule or JIT delivery schedule) has run up against an error, causing processing to be terminated.
In this case the cause of the error is 6.
System Response
The error may involve one of the following situations:
1: The nature of the error cannot be specified precisely.
2: The forecast delivery schedule or the JIT delivery schedule was generated but no message record could be generated.
3: A document type for which the functions "Generate forecast delivery schedule" or "Generate JIT delivery schedule" are not defined may be involved.
4: A material for which the function "Generate JIT delivery schedule" is not defined may be involved.
5: A scheduling agreement that has not yet been released by all persons responsible may be involved.
6: The factory calendar has not been maintained correctly.
Procedure
Error source 1:
Check whether the vendor and plant shown in the PO actually exist in the system.
Error source 2:
Check the Customizing facility for message determination with respect to delivery schedules created under scheduling agreements (print operation '9').
Error source 3:
In Customizing, maintain the document types accordingly ( Define document types for scheduling agreement). Then create a new scheduling agreement with a document type for which release documentation is defined.
Error source 4:
Maintain the JIT delivery schedule indicator in the material master record.
Error source 5:
Have the scheduling agreement released by the person(s) responsible.
Error source 6:
If you are using a release creation profile without aggregation, you must maintain the factory calendar for the next 999 days
Regards,
SantoshHello Mallinath,
I referred the note and following are the observarion in the system.
Step1:Run T-code SE16 (table T001W) to check the calendar ID of the plant.
-----Referred the Calendor ID
Step2: Check the JIT/Forecast delivery schedule of release creation profile in customizing. (T-code OLME -> Scheduling Agreement -> Maint. Rel. Creation Profile for Sched. Agmt. w. Rel. Docu.)
Run T-code SCAL to adjust the period of the calendar ID which checked in STEP 1 according to the JIT/Forecast delivery schedule of the release creation profile which checked in STEP 2.
(For example, if the JIT/Forecast delivery schedule of the release creation profile is "999" days, then the calendar should be extended for the next 999 days at least)
---------In this case factory calendor is valid till 2015 and according to note needs to change the factory calendor till 2018( or for 999 days) ?
Waiting for your inputs.
Thanking you,
Santosh -
IDOC should be created when PO RELEASED Using ME29N Transaction?
Hi,
Can anyone suggest me how to create ACCESS SEQUENCE,PROCESS ROUTINES,CONDITION RECORD and all steps in NACE Transaction.
our requirement is that the IDOC Should get Created Only after Purchase Order is Released using ME29N transaction.
Can anyone tell how to create IDOC and Send that IDOC to Receipient system for a Purchase Order that is already Released using ME29N transactionthank u
-
Container-managed / bean-managed transaction demarcation
I am trying to make sure I understand container-managed and bean-managed transaction demarcation and in particular where you have one bean calling another bean. What happens where one of the beans has container-managed transaction demarcation and the other bean-managed transaction demarcation. In fact the initial question to ask is, is this allowed?
Lets use an application scenario to illustrate the issue. The application has a payment transaction. Payments can be received in one of two ways:
1. As a payment at a branch where the individual payment is processed on a client application and resulting in the processing of a single payment transaction.
2. As a batch of payments received from a bank containing, potentially, thousands of payment transactions.
The proposed implementation for this uses two session beans. The first is a Payment session bean that implements the business logic as appropriate calling entity beans to persist the change. The second is a BatchPayment session bean. This processes the batch of payment transactions received from the bank. The BatchPayment reads through the batch of payments from a bank calling the Payment session bean for each payment transaction.
Lets look at the transactional properties of both session beans. In order to support the client application the Payment session bean can implicitly enforce transactional integrity and is therefore set to container-managed transaction demarcation. However the BatchPayment session bean will want to explicitly specify transaction demarcation for performance reasons. The transactional "commit" process is relatively expensive. When processing a large batch of transactions rather than performing a commit after every transaction is processed we want to perform the commit after a number of transactions have been processed. For example, we may decide that after every 100 transactions have been processed we commit. The processing will have a shorter elapsed time as we have not had to perform 99 commit processes. So the BatchPayment session bean will want to explicitly specify its transaction demarcation and will therefore be defined with bean-managed transaction demarcation.
How would this be implemented? A possible solution is:
Payment session bean implemented with container-managed transaction demarcation with transaction scope set to Required.
BatchPayment session bean implemented with bean-managed transaction demarcation with transaction scope set to Required.
When the client application is run it calls the Payment bean and the container-managed transaction demarcation ensures the transactional integrity of that transaction.
When a BatchPayment process is run it explicitly determines the transaction demarcation. Lets say that after every 100 Payment transactions (through 100 calls to the Payment session bean) have been processed the BatchPayment bean issues a commit. In this scenario however we have mixed container-managed and bean-managed transaction demarcation. Hence my original question. Can container-managed and bean-managed transaction demarcation be mixed? If not how is it possible to implement the requirements as described above?
Thanks for any thoughts.
PaulBatchPayment session bean implemented with bean-managed transaction demarcation with transaction scope set to Required.Didn't quite understand this sentence.... if it's BMT it has no declarative transaction attributes such as "Required"....
Anyway, first of all I'll have to ask, Why at all would you want to commit in the middle of the business method? to get as much through as possible before a potential crash? :-)
Can container-managed and bean-managed transaction demarcation be mixed?Yes, of course. Just remember that the "direction" you are refering to ->
a BMT SB that propagates it's transaction to a method in a CMT SB that is demarcated with "Required" is the simplest case. If it were "reversed", or for that matter any BMT that might be called within an active transaction context must perform logic to manipulate the transaction state. For instance(and most common case), checking to see if a transaction is active and if so not to do anything(just use the one that is already active).
If not how is it possible to implement the requirements as described above?You could also implement this scenario with CMTs all the way through. your BatchPayment SB could consist of two methods, one (say, execute(Collection paymentsToExecute) ) with "Supports", and another(say executeBatchUnit(Collection paymentsToExecute, int beginIndex, int endIndex) ) with "RequiresNew".
then have the first just call the other with indexes denoting each time a group of payments.
Still, it does seem more suitable using BMT for these kind of things.....
Hope this helped.... -
Max Beans in Cache causes NULL Pointer Exception
Hi All,
a rather weird event (from our perspective) occurs when we do the
following:
We have an entity bean set to max beans in cache 100 (default value of
our deployment tool ), the database table related to that bean holds
lets say 300 entries.
Doing a find all and in the same session bean instanciated transaction a
processing loop over the enumeration of beans we get an NULL Pointer
exception when accesing the 101 Bean. Neverthless the Weblogic server
increases the cache size automatically but obviously not fast enough and
not on time.
has anyone experienced the same problem and has a fix for it, appart
from increasing the cache size in the deployment descriptor ?
any help welcome
MichaelHi Michael.
Can you post the stack trace of the NullPointerException? Was it in
your code or ours? Also, what version of WebLogic are you using?
-- Rob
Rob Woollen
Software Engineer
BEA WebLogic
[email protected]
Michael Rupprecht wrote:
Hi All,
a rather weird event (from our perspective) occurs when we do the
following:
We have an entity bean set to max beans in cache 100 (default value of
our deployment tool ), the database table related to that bean holds
lets say 300 entries.
Doing a find all and in the same session bean instanciated transaction a
processing loop over the enumeration of beans we get an NULL Pointer
exception when accesing the 101 Bean. Neverthless the Weblogic server
increases the cache size automatically but obviously not fast enough and
not on time.
has anyone experienced the same problem and has a fix for it, appart
from increasing the cache size in the deployment descriptor ?
any help welcome
Michael -
About Container-managed Transactions and Bean-managed Transactions
as the document of weblogic7.0 describe the differents of Container-managed
Transactions and Bean-managed Transactions,and in the document,It tell us
details of using Bean-managed Transactions,such as \:
import javax.naming.*;import javax.transaction.UserTransaction;.....
import java.sql.*;import java.util.*;
UserTransaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");tx.begin();
tx.commit() //or tx.rollback
but how to use Container-managed Transactions?
what is EJB's deployment descriptor? can someone tell me?
i wonder someone will show me an example of how to use Container-managed
Transactions.
thanks
fish
Many if not all of the WLS EJB examples use container-managed
transactions. That's a good place to start.
I'd also recommend that you pick up a decent EJB book. There's several
on the market right now.
-- Rob
fish wrote:
> <ejb-jar>
> <enterprise-beans>
> <session>
> <ejb-name>testbean</ejb-name>
> <home>test.test.TestHome</home>
> <remote>test.test.Test</remote>
> <ejb-class>test.test.TestBean</ejb-class>
> <session-type>Stateful</session-type>
> <transaction-type>Container</transaction-type>
> </session>
> </enterprise-beans>
>
> <assembly-descriptor>
> <container-transaction>
> <method>
> <ejb-name>EmployeeRecord</ejb-name>
> <method-name>*</method-name>
> </method>
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
> </assembly-descriptor>
> </ejb-jar>
> ----------------------------------------------
> seems i have to write ejb-jar.xml like this,am i right?
> what about <ejb-client-jar>? is it needed in this xml file?
>
> thanks
>
> fish
>
>
-
hi,erveryone,
one difficult question need help.
Environment: WLS8.1sp2 + WLI8.1sp2 + ORACLE9i + solaris9
when I started archiver manually,just for a while, wli system generated about 40,000 JMS messages in
wli.internal.worklist.timer.queue,and consume the great mass of system resource of Database server,I had to stop these
archive processes immediately to keep other applicaitons which using the same database running normal. I did so by
following steps:
(1) in WLI console, delete wli.internal.worklist.timer.queue;
(2) in WLI console, reconstruct wli.internal.worklist.timer.queue;
(3) restart wli server.
after server was restarted, wli server output endless and repeatly exception to log file ,the typical exception was:
####<May 8, 2005 3:08:26 PM CST> <Info> <EJB> <app01> <jcwliserver> <ExecuteThread: '54' for queue:
'weblogic.kernel.Default'> <<anonymous>> <BEA1-54B26B551CC1A8856F80> <BEA-010049> <EJB Exception in method: remove:
java.sql.SQLException: Transaction rolled back: Unknown reason.
java.sql.SQLException: Transaction rolled back: Unknown reason
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1299)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1250)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:385)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:343)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:305)
at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.getConnection(RDBMSPersistenceManager.java:2247)
at
com.bea.wli.worklist.beans.entity.ListenerBean_1nsp14__WebLogic_CMP_RDBMS.__WL_loadGroup0(ListenerBean_1nsp14__WebLogic_CMP_R
DBMS.java:1055)
at
com.bea.wli.worklist.beans.entity.ListenerBean_1nsp14__WebLogic_CMP_RDBMS.__WL_setTaskBean_listeners(ListenerBean_1nsp14__Web
Logic_CMP_RDBMS.java:596)
at
com.bea.wli.worklist.beans.entity.ListenerBean_1nsp14__WebLogic_CMP_RDBMS.__WL_setTaskBean_listeners(ListenerBean_1nsp14__Web
Logic_CMP_RDBMS.java:584)
at
com.bea.wli.worklist.beans.entity.ListenerBean_1nsp14__WebLogic_CMP_RDBMS.ejbRemove(ListenerBean_1nsp14__WebLogic_CMP_RDBMS.j
ava:2423)
at weblogic.ejb20.manager.DBManager.remove(DBManager.java:1318)
at weblogic.ejb20.internal.EntityEJBLocalHome.remove(EntityEJBLocalHome.java:214)
at
com.bea.wli.worklist.beans.entity.ListenerBean_1nsp14_LocalHomeImpl.remove(ListenerBean_1nsp14_LocalHomeImpl.java:131)
at
com.bea.wli.worklist.beans.session.RemoteWorklistManagerBean.removeTaskListeners(RemoteWorklistManagerBean.java:3001)
at
com.bea.wli.worklist.beans.session.RemoteWorklistManagerBean_us8t1c_EOImpl.removeTaskListeners(RemoteWorklistManagerBean_us8t
1c_EOImpl.java:698)
at com.bea.wli.worklist.timer.WorklistTimerMDB.processListenerToRemove(WorklistTimerMDB.java:102)
at com.bea.wli.worklist.timer.WorklistTimerMDB.onMessage(WorklistTimerMDB.java:61)
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)
>
####<May 8, 2005 3:08:26 PM CST> <Info> <EJB> <app01> <jcwliserver> <ExecuteThread: '96' for queue:
'weblogic.kernel.Default'> <<anonymous>> <BEA1-54B96B551CC1A8856F80> <BEA-010049> <EJB Exception in method: remove:
javax.ejb.NoSuchEntityException: [EJB:010140]Bean with primary key: '153.22.52.28-17343c7.10243c3c6ec.a51' not found..
javax.ejb.NoSuchEntityException: [EJB:010140]Bean with primary key: '153.22.52.28-17343c7.10243c3c6ec.a51' not found.
at
com.bea.wli.worklist.beans.entity.ListenerBean_1nsp14__WebLogic_CMP_RDBMS.__WL_loadGroup0(ListenerBean_1nsp14__WebLogic_CMP_R
DBMS.java:1165)
at
com.bea.wli.worklist.beans.entity.ListenerBean_1nsp14__WebLogic_CMP_RDBMS.__WL_setTaskBean_listeners(ListenerBean_1nsp14__Web
Logic_CMP_RDBMS.java:596)
at
com.bea.wli.worklist.beans.entity.ListenerBean_1nsp14__WebLogic_CMP_RDBMS.__WL_setTaskBean_listeners(ListenerBean_1nsp14__Web
Logic_CMP_RDBMS.java:584)
at
com.bea.wli.worklist.beans.entity.ListenerBean_1nsp14__WebLogic_CMP_RDBMS.ejbRemove(ListenerBean_1nsp14__WebLogic_CMP_RDBMS.j
ava:2423)
at weblogic.ejb20.manager.DBManager.remove(DBManager.java:1318)
at weblogic.ejb20.internal.EntityEJBLocalHome.remove(EntityEJBLocalHome.java:214)
at
com.bea.wli.worklist.beans.entity.ListenerBean_1nsp14_LocalHomeImpl.remove(ListenerBean_1nsp14_LocalHomeImpl.java:131)
at
com.bea.wli.worklist.beans.session.RemoteWorklistManagerBean.removeTaskListeners(RemoteWorklistManagerBean.java:3001)
at
com.bea.wli.worklist.beans.session.RemoteWorklistManagerBean_us8t1c_EOImpl.removeTaskListeners(RemoteWorklistManagerBean_us8t
1c_EOImpl.java:698)
at com.bea.wli.worklist.timer.WorklistTimerMDB.processListenerToRemove(WorklistTimerMDB.java:102)
at com.bea.wli.worklist.timer.WorklistTimerMDB.onMessage(WorklistTimerMDB.java:61)
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)
>
The wli server generated log file very quickly ,:it can output 1M bytes log file per second,all logged information
is similar to the <BEA-010049> excetpion metioned above. BEA support engineer suggested me to totally stop the
archive ,I did so,but the server was still ouput the log file like crazy as before and the normal log information are
completely override by <BEA-010049> excetpion.
I checked the EntityEJBs in WLI console :Mywlidomain> Applications> WLI System EJBs> WLI Worklist Persistence$)A#,and
found that in statistics table :
ListenerBean : Pool miss ratio = 99.67%, transaction rollback ration = 99.90%,Destory Bean Ratio = 99.48%(see
attachment)
WorklistTimerMDB: transaction rollback ratio = 99.97%
It seems ListenerBean worked incorrectly.I searched in support.bea.com and found one example which also about server
output endless log file,the author solved this problem by changing Bean's transaction-attribute from 'Required'
to 'RequiresNew' thought he didn't know why it works. I try this method by changing ListenerBean's
transaction-attribute from 'Required' to 'RequiresNew'.
$weblogic_home/integration/lib/wli-ejbs.ear/ejb-jar-generic.xml:
<ejb-name>CommentBean</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>ListenerBean</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>RequiresNew</trans-attribute> -----------the default value is Required,I modified it to
RequiresNew.
</container-transaction>
<container-transaction>
really it works, the log file output resume normal. But there are still some problems:
(1) this exception is still exist:
javax.ejb.NoSuchEntityException: [EJB:010140]Bean with primary key: '153.22.52.28-17343c7.10243c3c6ec.a51' not found.
(2) is this method safe ?(Does "Modify ListenBean's transaction-attribute" impat other parts of wli system?)
(3) after changed the transaction attribute, if turn on archive again, the server output endless exception:
####<Jun 1, 2005 5:14:58 PM CST> <Info> <EJB> <app01> <jcwliserver> <ExecuteThread: '63' for queue:
'weblogic.kernel.Default'> <<anonymous>> <BEA1-2F43890B86B0A8856F80> <BEA-010036> <Exception from ejbStore:
java.sql.SQLException: XA error: XAER_RMERR : A resource manager error has occured in the transaction branch start()
failed on resource 'weblogic.jdbc.jta.DataSource': XAER_RMERR : A resource manager error has occured in the transaction
branch
oracle.jdbc.xa.OracleXAException
at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1160)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:311)
at weblogic.jdbc.wrapper.VendorXAResource.start(VendorXAResource.java:50)
at weblogic.jdbc.jta.DataSource.start(DataSource.java:617)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1075)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1007)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:218)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:419)
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1287)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1250)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:385)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:343)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:305)
at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.getConnection(RDBMSPersistenceManager.java:2247)
at
com.bea.wli.worklist.beans.entity.TaskBean_9fxazu__WebLogic_CMP_RDBMS.__WL_store(TaskBean_9fxazu__WebLogic_CMP_RDBMS.java:363
6)
at
com.bea.wli.worklist.beans.entity.TaskBean_9fxazu__WebLogic_CMP_RDBMS.ejbStore(TaskBean_9fxazu__WebLogic_CMP_RDBMS.java:3548)
at weblogic.ejb20.manager.DBManager.beforeCompletion(DBManager.java:927)
at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:745)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1010)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:115)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:1142)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1868)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:250)
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)
java.sql.SQLException: XA error: XAER_RMERR : A resource manager error has occured in the transaction branch start()
failed on resource 'weblogic.jdbc.jta.DataSource': XAER_RMERR : A resource manager error has occured in the transaction
branch
oracle.jdbc.xa.OracleXAException
at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1160)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:311)
at weblogic.jdbc.wrapper.VendorXAResource.start(VendorXAResource.java:50)
at weblogic.jdbc.jta.DataSource.start(DataSource.java:617)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1075)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1007)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:218)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:419)
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1287)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1250)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:385)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:343)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:305)
at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.getConnection(RDBMSPersistenceManager.java:2247)
at
com.bea.wli.worklist.beans.entity.TaskBean_9fxazu__WebLogic_CMP_RDBMS.__WL_store(TaskBean_9fxazu__WebLogic_CMP_RDBMS.java:363
6)
at
com.bea.wli.worklist.beans.entity.TaskBean_9fxazu__WebLogic_CMP_RDBMS.ejbStore(TaskBean_9fxazu__WebLogic_CMP_RDBMS.java:3548)
at weblogic.ejb20.manager.DBManager.beforeCompletion(DBManager.java:927)
at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:745)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1010)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:115)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:1142)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1868)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:250)
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)
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1292)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1250)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:385)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:343)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:305)
at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.getConnection(RDBMSPersistenceManager.java:2247)
at
com.bea.wli.worklist.beans.entity.TaskBean_9fxazu__WebLogic_CMP_RDBMS.__WL_store(TaskBean_9fxazu__WebLogic_CMP_RDBMS.java:363
6)
at
com.bea.wli.worklist.beans.entity.TaskBean_9fxazu__WebLogic_CMP_RDBMS.ejbStore(TaskBean_9fxazu__WebLogic_CMP_RDBMS.java:3548)
at weblogic.ejb20.manager.DBManager.beforeCompletion(DBManager.java:927)
at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:745)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1010)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:115)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:1142)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1868)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:250)
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)
>
How can I solve these problem ? any suggestion is warm welcome.
Thanks in advance.
Great LouBack up all data to at least two different storage devices, if you haven't already done so. The backups can be made with Time Machine or with a mirroring tool such as Carbon Copy Cloner. Preferably both.
Boot into Recovery (command-R at startup), launch Disk Utility, and erase the startup volume with the default options.This operation will destroy all data on the volume, so you had be better be sure of your backups. Quit Disk Utility and install OS X. When you reboot, you'll be prompted to go through the initial setup process. That’s when you transfer the data from one of your backups. For details of how this works, see here:
Using Setup Assistant
Transfer only "Users" and "Settings" – not "Applications" or "Other files." Don't transfer the Guest account, if it was enabled on the old system. Test. If the problem is still there, you have a hardware fault. Take the machine to an Apple Store for diagnosis.
If the problem is resolved, reinstall your third-party software cautiously. Self-contained applications that install into the Applications folder by drag-and-drop or download from the App Store are safe. Anything that comes packaged as an installer or that prompts for an administrator password is suspect, and you must test thoroughly after reinstalling each such item to make sure you haven't restored the problem.
Note: You need an always-on Ethernet or Wi-Fi connection to the Internet to use Recovery. It won’t work with USB or PPPoE modems, or with proxy servers, or with networks that require a certificate for authentication. -
Bean-Managed Transaction and xDoclet
Hi,
i am new by xDoclet.
Does anybody know, how to specify Bean-Managed Transaction by EJB using xDoclet.
Thank you very much for any hint or link.
--EugenThanks Dhiraj for helping,
I have a application module called TestAppModule. TestAppModule should be deployed as Bean Managed Service Bean. In the Remote of the Application Module, I chose BmtServiceBean. 3 files were created
RemoteTestAppModule.java
TestAppModuleHome.java
TestAppModuleServer.java
In ejb-jar.xml, this tag was added
<enterprise-beans>
<session>
<description>Session Bean ( Stateful )</description>
<display-name>TestAppModule</display-name>
<ejb-name>testBc4jComponents.TestAppModule_bmservice</ejb-name>
<home>testBc4jComponents.common.serviceejb.beanmanaged.TestAppModuleHome</home>
<remote>testBc4jComponents.common.serviceejb.beanmanaged.RemoteTestAppModule</remote>
<ejb-class>testBc4jComponents.server.serviceejb.beanmanaged.TestAppModuleServer</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Bean</transaction-type>
</session>
</enterprise-beans>
In Orion-ejb-jar.xml
<session-deployment name="testBc4jComponents.TestAppModule_bmservice"/>
I deployed the bean into oc4j.
In the Bean Where I am managing the Transaction.
Context ctx = new InitialContext();
Object home = ctx.lookup("testBc4jComponents.TestAppModule_bmservice");
TestAppModuleHome testAppHome = (TestAppModuleHome) PortableRemoteObject.narrow(home, TestAppModuleHome.class);
When I am looking up the Appmodule Bean, I reached an error stating "Serialization Error, The TestAppModuleImpl is not Serializable"
Please let me know what I am doing wrong?
Thanks
Senthil -
Bean Managed Transactions and rollback
Hi Everybody,
I am using Bean Managed Transactions in a Message Bean which is called every some time by an EJB3 timer. This Message Bean subsequently calls a Session Bean which uses Container Managed Transactions and uses the default transaction attribute which is SUPPORTS. The Session Bean methods might sometime throw a System Exception(inheriting from RuntimeException) which will rollback the Bean Managed Transaction which was started from the Message Bean.
When this happens and I try to invoke userTransaction.rollback() I get invalid transaction state exception and I suppose this means that is already rolled back.
Is there a way to get another transaction or set the transaction back to a valid state so I can carry on with some persistence tasks or the only way to do that is by suppressing the RuntimeException and throwing an Application Exception having the *@ApplicationException(rollback=false)* annotation? Can I suppress a System Exception though?
Thank you in advance!Saroj wrote:
Hi All,
I would like to know whether we can use JDBC Connection Object's commit and rollback
methods to control Transaction in Bean Managed Transactions or not.You may use the JDBC connection's transaction support from an EJB. That being said, you
need to understand that it won't be the transaction that started declaratively by the
EJB container nor would it be a bean-managed transaction started through
UserTransaction.
FWIW, I question why you'd want to do this though. I'd use container-managed
transactions and let the container handle this for you. The transaction manager
includes a 1PC optimization so it's not going to do an XA/2PC tx if you only have a
single resource in the tx. Also, the EJB container includes all the logic to properly
handle rollbacks when exceptions are thrown etc.
Finally, your code will more maintainable and reusable if you use the container-managed
tx + JTA resources. If I later wanted to call another EJB or another JTA resource (eg
JMS perhaps) I could do it without having to rewrite all of your code.
-- Rob
>
>
Why is it required that we should use Java Transaction API to control the Transaction
in Our Beans?
I understand that if we are using Multiple Resources and need to use Transaction
then going for JTA makes sense. If I am using only Resource,for example, Only One
Connection then we should be able to use Connection's Transaction control.
I understand that other way to do the transaction is to use Container's transaction
services.
Please respond at the earliest.
Thanks in Advance,
Saroj -
Sap Error generating release against scheduling agreement (cause 2)
Hi,
Please help me on this issue
Error generating release against scheduling agreement (cause 2)
Message no. 06857
Regards
AmeyHi,
For EDI you might be missing settings in:
1) Matrl Mng -> Purchasing -> Messages -> Output control -> Output types -> Define Message Types for Scheduling Agreement Release/Expediter -> Fine-Tuned Control: Forecast Delivery Schedule/Expediter (check one of the outputs for 9 and for A )
2) WE20 - EDI settings for partner that is a vendor who should receive your release information DELFOR / DELJIT (if you do not manage other EDI settings then also other WEDI setings should be maintained)
Best Regards,
Tomek -
Cannot remove stateful session bean when transaction timed out
The transaction timeout is set to 5 minutes. After several operations on the transactional
stateful session bean(implements SessionSynchronization), the transaction timed out
after 5 minutes and I got the IllegalStateException when calling another business
method. After the transaction rolled back, weblogic.ejb20.locks.LockTimedOutException
was thrown when attempting to remove the bean. It seems the lock on the bean was
not released even though the transaction had been rolled back. Does anyone know how
to remove the bean in this kind of situation?
Here is the stacktrace:
####<Jun 11, 2002 2:39:35 PM PDT> <Notice> <EJB> <app1x.zaplet.cc> <server25044server>
<ExecuteThread: '11' for queue: 'default'> <> <23168:7b09681c532dc7e3> <010015> <Error
marking transaction for rollback: java.lang.IllegalStateException: Cannot mark the
transaction for rollback. xid=23168:7b09681c532dc7e3, status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException:
Transaction timed out after 299 seconds
Xid=23168:7b09681c532dc7e3(3203140),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=299,seconds left=60,activeThread=Thread[ExecuteThread: '11' for queue:
'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[server25044+server25044server]=(state=active),properties=({weblogic.jdbc=t3://10.0.100.93:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=server25044server+10.0.100.93:7001+server25044+,
Resources={})],CoordinatorURL=server25044server+10.0.100.93:7001+server25044+)]>
java.lang.IllegalStateException: Cannot mark the transaction for rollback. xid=23168:7b09681c532dc7e3,
status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction
timed out after 299 seconds
Xid=23168:7b09681c532dc7e3(3203140),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=299,seconds left=60,activeThread=Thread[ExecuteThread: '11' for queue:
'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[server25044+server25044server]=(state=active),properties=({weblogic.jdbc=t3://10.0.100.93:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=server25044server+10.0.100.93:7001+server25044+,
Resources={})],CoordinatorURL=server25044server+10.0.100.93:7001+server25044+)]
at weblogic.transaction.internal.TransactionImpl.throwIllegalStateException(TransactionImpl.java:1486)
at weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:466)
at weblogic.ejb20.manager.BaseEJBManager.handleSystemException(BaseEJBManager.java:255)
at weblogic.ejb20.manager.BaseEJBManager.setupTxListener(BaseEJBManager.java:215)
at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:371)
at weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:117)
at weblogic.ejb20.internal.StatefulEJBObject.preInvoke(StatefulEJBObject.java:169)
at mypackage.MyBean_wbr3eg_EOImpl.addRecipients(MyBean_wbr3eg_EOImpl.java:450)
####<Jun 11, 2002 2:39:37 PM PDT> <Info> <EJB> <app1x.zaplet.cc> <server25044server>
<ExecuteThread: '11' for queue: 'default'> <> <> <010049> <EJB Exception in method:
remove: weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:AppmailBean
with primary key:21,775,960,933,010,237 timed-out after waiting 0 ms. The transaction
or thread requesting the lock was:Thread[ExecuteThread: '11' for queue: 'default',5,Thread
Group for Queue: 'default'].>
weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:AppmailBean
with primary key:21,775,960,933,010,237 timed-out after waiting 0 ms. The transaction
or thread requesting the lock was:Thread[ExecuteThread: '11' for queue: 'default',5,Thread
Group for Queue: 'default'].
at weblogic.ejb20.locks.ExclusiveLockManager$LockBucket.lock(ExclusiveLockManager.java:448)
at weblogic.ejb20.locks.ExclusiveLockManager.lock(ExclusiveLockManager.java:258)
at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:226)
at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:216)
at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:310)
at weblogic.ejb20.manager.StatefulSessionManager.remove(StatefulSessionManager.java:754)
at weblogic.ejb20.internal.StatefulEJBObject.remove(StatefulEJBObject.java:86)
at mypackage.MyBean_wbr3eg_EOImpl.remove(MyBean_wbr3eg_EOImpl.java:7308)If a stateful session throws a RuntimeException (your rollback) the container destroys the instance of the bean and all
associated state information is lost, as required by the EJB specification.
If you want to maintain client state it is generally best to use HttpSession objects (if you have a web application)
for short-lived, client-specific data and JPA entities or other database backed storage for long-lived data. -
JDBInsight 2.0 Released - True JDBC Transaction Analysis !!!
Check out the new product release and revised documentation at:
http://www.jinspired.com/products/jdbinsight/downloads/index.html
PRESS RELEASE
=============
DUBLIN, IRELAND - 29th October, 2003 - JInspired (www.jinspired.com), a leader
in J2EE(tm) transaction analysis, today announced JDBInsight 2.0, the next generation
of J2EE performance management products from JInspired.
JDBInsight is the first product to effectively integrate Java profiling information
with JDBC/SQL transaction analysis. Version 2.0 has numerous features derived
from its support of the Java VM Profiling Interface(JVMPI) such as Java call stack
analysis, cpu, blocking and waiting measurements at the transaction path level.
Clock measurements are adjusted for blocking, waiting and gc pauses. New features
in this release
- New console user interface: Many new informative visualizations of J2EE transactions
and performance execution profiles have been added. Including call stack graphs,
entry point tree maps, sequence diagrams, call stack and transaction transcripts.
Additional views included allow for navigation of the performance profile via
database table or column, Java package, class, or method, technology classification,
SQL tokens, or transaction entry points.
- Java call stack classification engine: Developers, testers, database and J2EE
server administrators can now better understand the interaction of various Java
enterprise technologies with corporate databases. Classifications are available
for Java enterprise technologies such as EJB, Hibernate, JDO, JMS, JSP, Servlets,
JTS, JDBC, and Struts.
- Terminal services: The terminal services add-on provides a quick and easy way
to communicate with multiple servers without having to use a graphical user interface.
This facilitates the streamlined connection, activation and deactivation of profiles
on local or remote servers with the ability to control multiple servers from a
single terminal. The terminal environment provides a powerful environment to create
and schedule snapshot information, in order to monitor servers at regular intervals,
with the ability to store and retrieve snapshots from any mounted drive, as well
as providing a rich set of commands, that can be executed from saved scripts,
to assist in analysis of this highly detailed profile data.
- Transaction demarcations: JDBInsight 2.0 is the first performance management
product to have the ability to detect and present resource transaction demarcations
- allowing visual sub-transaction identification.
- Resource Management: JDBInsight keeps counters representing objects states for
each JDBC interception point create a resource object. When a JDBC resource changes
state the allocation site counters are updated. This helps to pinpoint source
code locations where resource objects are created and not closed properly or freed
from memory. Because an interception is a combination of call stack and SQL the
view caters for generic J2EE application frameworks which create objects based
on application parameters and callers.
- Xml export: Various statistical measurements can be viewed in Xml format and
copied into applications for custom report generation.
- Server options: Additional system properties to customize the small amount of
overhead added during runs.
About JDBInsight
JDBInsight is an innovative enterprise development product, aimed at simplifying
the performance tuning and testing of J2EE(tm) applications, which access data
through the Java Database Connectivity (JDBC(tm)) API. JDBInsight analyses the
access of enterprise data by J2EE(tm) client-, web-, and bean containers. The
analysis can encompass transaction executions, from multiple J2EE(tm) containers.
JDBInsight captures timing and execution information for enterprise data accessed
by Servlets, JavaServer Pages, Session- and Entity Beans using JDBC(tm) or an
Entity Bean using a container's persistence engine. JDBInsight can also profile
non-J2EE applications that access enterprise data through the JDBC(tm) API.
What distinguishes JDBInsight from other profiling and performance management
tools on the market is that JDBInsight provides analysis from a sequence perspective
instead of simply showing a call tree. Inefficiencies in J2EE applications occur
mainly at the transaction level such as repeating the execution of a particular
SQL locally and globally. JDBInsight facilitates the recognition of database interaction
patterns that exhibit inefficiencies when viewed in terms of the sequential execution
of a business and/or resource transaction.
About JInspired
JInspired located in Ireland, delivers JDBInsight, a comprehensive solution for
Application Performance Tuning and Testing that focuses directly on early identification
within the development and testing lifecycle. Jinspired offers sophisticated analytical
tools, that capture transactional behaviour and performance timing information,
across multiple containers in a single console, and presents this information
intuitively to the user "Visualizing the Invisible".Check out the new product release and revised documentation at:
http://www.jinspired.com/products/jdbinsight/downloads/index.html
PRESS RELEASE
=============
DUBLIN, IRELAND - 29th October, 2003 - JInspired (www.jinspired.com), a leader
in J2EE(tm) transaction analysis, today announced JDBInsight 2.0, the next generation
of J2EE performance management products from JInspired.
JDBInsight is the first product to effectively integrate Java profiling information
with JDBC/SQL transaction analysis. Version 2.0 has numerous features derived
from its support of the Java VM Profiling Interface(JVMPI) such as Java call stack
analysis, cpu, blocking and waiting measurements at the transaction path level.
Clock measurements are adjusted for blocking, waiting and gc pauses. New features
in this release
- New console user interface: Many new informative visualizations of J2EE transactions
and performance execution profiles have been added. Including call stack graphs,
entry point tree maps, sequence diagrams, call stack and transaction transcripts.
Additional views included allow for navigation of the performance profile via
database table or column, Java package, class, or method, technology classification,
SQL tokens, or transaction entry points.
- Java call stack classification engine: Developers, testers, database and J2EE
server administrators can now better understand the interaction of various Java
enterprise technologies with corporate databases. Classifications are available
for Java enterprise technologies such as EJB, Hibernate, JDO, JMS, JSP, Servlets,
JTS, JDBC, and Struts.
- Terminal services: The terminal services add-on provides a quick and easy way
to communicate with multiple servers without having to use a graphical user interface.
This facilitates the streamlined connection, activation and deactivation of profiles
on local or remote servers with the ability to control multiple servers from a
single terminal. The terminal environment provides a powerful environment to create
and schedule snapshot information, in order to monitor servers at regular intervals,
with the ability to store and retrieve snapshots from any mounted drive, as well
as providing a rich set of commands, that can be executed from saved scripts,
to assist in analysis of this highly detailed profile data.
- Transaction demarcations: JDBInsight 2.0 is the first performance management
product to have the ability to detect and present resource transaction demarcations
- allowing visual sub-transaction identification.
- Resource Management: JDBInsight keeps counters representing objects states for
each JDBC interception point create a resource object. When a JDBC resource changes
state the allocation site counters are updated. This helps to pinpoint source
code locations where resource objects are created and not closed properly or freed
from memory. Because an interception is a combination of call stack and SQL the
view caters for generic J2EE application frameworks which create objects based
on application parameters and callers.
- Xml export: Various statistical measurements can be viewed in Xml format and
copied into applications for custom report generation.
- Server options: Additional system properties to customize the small amount of
overhead added during runs.
About JDBInsight
JDBInsight is an innovative enterprise development product, aimed at simplifying
the performance tuning and testing of J2EE(tm) applications, which access data
through the Java Database Connectivity (JDBC(tm)) API. JDBInsight analyses the
access of enterprise data by J2EE(tm) client-, web-, and bean containers. The
analysis can encompass transaction executions, from multiple J2EE(tm) containers.
JDBInsight captures timing and execution information for enterprise data accessed
by Servlets, JavaServer Pages, Session- and Entity Beans using JDBC(tm) or an
Entity Bean using a container's persistence engine. JDBInsight can also profile
non-J2EE applications that access enterprise data through the JDBC(tm) API.
What distinguishes JDBInsight from other profiling and performance management
tools on the market is that JDBInsight provides analysis from a sequence perspective
instead of simply showing a call tree. Inefficiencies in J2EE applications occur
mainly at the transaction level such as repeating the execution of a particular
SQL locally and globally. JDBInsight facilitates the recognition of database interaction
patterns that exhibit inefficiencies when viewed in terms of the sequential execution
of a business and/or resource transaction.
About JInspired
JInspired located in Ireland, delivers JDBInsight, a comprehensive solution for
Application Performance Tuning and Testing that focuses directly on early identification
within the development and testing lifecycle. Jinspired offers sophisticated analytical
tools, that capture transactional behaviour and performance timing information,
across multiple containers in a single console, and presents this information
intuitively to the user "Visualizing the Invisible".
Maybe you are looking for
-
System/Query Performance: What to look for in these tcodes
Hi I have been researching on system/query performance in general in the BW environment. I have seen tcodes such as ST02 :Buffer/Table analysis ST03 :System workload ST03N: ST04 : Database monitor ST05 : SQL trace ST06 : ST66: ST21: ST22: SE30: ABAP
-
I have created a PO: 4000000231 to 4000000244 for Vendor A. I have done payments for the vendors for several bills against many POs. Now i want to know how much payment i have done against each PO. Let me how to get it (preferably without any work ar
-
BAMAdapter Issue : java.rmi.ConnectException: Destination unreachable;
Hi, I have installed SOA server and BAM server on same localhost but while calling BAM adapter from the BPEL process it's throwing below error. *<Jun 24, 2011 6:56:51 PM BST> <Error> <oracle.soa.bpel.engine.ws> <BEA-000000>* *<got FabricInvocationExc
-
[Newbie] JSP precompilation & dumps
Hey there, I've just gotten started on my first JSP project. I've done some extensive googling, but can't work out the following two issues. 1) One of my pages, takes around 10-15 seconds to load in the browser. I'm assuming thats because tomcat is p
-
Another Printing (CUPS) permission issue
I have just upgraded to 10.5.2 (and the recent security update), and printing stopped. Whenever I try to print, the job is spooled successfully, then I get: unable to open print file "/private/var/spool/cups/d05259-001" - Permission denied. Help plea