SetAttribute() doesn't affect transaction state

I have BC4J JSP application and I have problem with one my ViewObject, it is very similar as the other my ViewObjects, is it based on one Entity and it is on third level master-detail (master-detail1-myVOdetail2).
But its behavior is very strange.
1) I call setAttribute("attrName"), no matter which attribute it is. (getAttribute() returns a new value).
2) I call Transaction.isDirty() -> false returned!!!!
3) I make some change, setAttribute() on the other ViewObject.
4) I call Transaction.isDirty() -> true returned.
5) I call commit() -> both changes made by points 1. and 3. are posted and commited to database.
It is very strange - may be some bc4j bug? Or some my mistake. I never have meet this problem before...
Have you any idea, what's the problem?
The problem is normally repeatable. My JDev version is 9.0.4.
Thank you very much for any comment.
Jan

repost

Similar Messages

Encountering transaction statement from within a PL/SQL block

Hi All,
i would like to know what will be the transaction status if we use an commit or a rollback statement inside a PL/SQL procedure called from within an PL/SQL package.
For example
BEGIN
select statement
insert statement 1
.... call to <xyz> procedure
end;
xyz procedure
insert statement 2
commit/rollback
end of procedure
will the insert statement 1 be commited/rollbacked when the session encounters the transaction statement inside the procedure.

Welcome to the forum!
Unless the procedure xyz is an autonomous transaction, then yes Insert statement 1 will be committed.

Transaction state BUG in TP3?

Hello,
I'm trying to make a backing bean that I have used in some Jdev 10.1.3.2 ADF Faces applications to retrieve the transaction state from an EL expression in a jspx page. I use it to disable some functions in the page when there are pending changes, and so force the user to save or discard them before making anything else.
The bean declaration int adfc-config.xml is:
<managed-bean>
<managed-bean-name>transaccion</managed-bean-name>
<managed-bean-class>viewcontroller.backing.Transaccion</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>bindings</property-name>
<value>#{bindings}</value>
</managed-property>
</managed-bean>
and the bean implementation is:
package viewcontroller.backing;
import oracle.adf.model.binding.DCBindingContainer;
public class Transaccion
private DCBindingContainer bindings;
public void setBindings(DCBindingContainer bindings) {
this.bindings = bindings;
public DCBindingContainer getBindings() {
return bindings;
public boolean getIsDirty()
boolean dirty = getBindings().getBindingContext().getDefaultDataControl()
.getApplicationModule().getTransaction().isDirty();
return dirty;
I have put the following element in a JSF page to test it:
<af:outputText value="#{transaccion.isDirty}" />
and I always get a false value.
I have also tried the following code in the bean class:
public boolean getIsDirty()
boolean dirty = getBindings().getBindingContext().getDefaultDataControl()
.isTransactionDirty();
return dirty;
with the same result.
Is it a bug?
Thanks,
Marc

Hi,
I don't think it is a partial submit. I submit the form with normal command buttons like these ones:
<af:commandButton text="Submit"
binding="#{backing_marcas.commandButton1}"
id="commandButton1"/>
<af:commandButton actionListener="#{bindings.CreateInsert.execute}"
text="CreateInsert"
disabled="#{!bindings.CreateInsert.enabled}"
binding="#{backing_marcas.commandButton6}"
id="commandButton6"/>
Furthermore, these commit and rollback buttons activate and deactivate correctly without need of using PPR refresh:
<af:commandButton actionListener="#{bindings.Commit.execute}"
text="Commit"
disabled="#{!bindings.Commit.enabled}"
binding="#{backing_marcas.commandButton7}"
id="commandButton7"/>
<af:commandButton actionListener="#{bindings.Rollback.execute}"
text="Rollback"
disabled="#{!bindings.Rollback.enabled}"
immediate="true"
binding="#{backing_marcas.commandToolbarButton1}"
id="commandToolbarButton1">
<af:resetActionListener/>
</af:commandButton>
And if I print the value of the dirty variable in the getIsDirty function of the bean class, I also get a false value.
Thanks,
Marc

How to verify transaction state under a tab in Dynamic Tabs UI Shell?

Hi,
I'm using Dynamic Tabs UI Shell to load taskflows under dynamic tabs. If a particular taskflow under a tab becomes dirty, upon close I should warn the user. What is the best way I could check if this particular taskflow has become dirty?
Thanks,
Pramod Gujjeti
Edited by: pramod gujjeti on Jun 16, 2010 1:28 AM
Edited by: pramod gujjeti on Jun 16, 2010 1:29 AM

Hi Pino,
Thanks for the reply.
The given URL only handles scenarios assuming a region from a flow has no flow embedded within it. And it seems to be not a generic approach to handle dynamic tab close.
I'd worked on a similar but more generic approach which could of use to this thread watchers, hence posting the code:
In the method that is invoked on tab close:
boolean isTransDirty = false; // holds the transaction state of the dynamic tab content for which close event is fired
try{
DCBindingContainer dcBindingContainer = (DCBindingContainer) AdfUtils.resolveExpression("#{bindings}");
dcBindingContainer = (DCBindingContainer)dcBindingContainer.getExecutableBindings().get(this.getSelectedTabIndex());
if(dcBindingContainer != null){
for( Object exeBinding : dcBindingContainer.getExecutableBindings() ) {
isTransDirty = isTransDirty(exeBinding);
if(isTransDirty){
break;
System.out.println(" is Trans Dirty : " + isTransDirty);
}catch(Exception e){
e.printStackTrace();
// method isTransDirty(Object ..)
private boolean isTransDirty(Object exeBinding){
boolean isDirty = false;
try{
if(exeBinding instanceof JUIteratorBinding ){
JUIteratorBinding juIteratorBinding = (JUIteratorBinding) exeBinding;
System.out.println(" Iterator : " juIteratorBinding.getName() "\t" + "D.C : " + juIteratorBinding.getDataControl().getName());
isDirty = juIteratorBinding.getDataControl().isTransactionDirty();
if(isDirty){
System.out.println(" Dirty because of " + juIteratorBinding.getName());
return isDirty;
}else if(exeBinding instanceof DCTaskFlowBinding){
DCTaskFlowBinding dcTaskFlowBinding = (DCTaskFlowBinding) exeBinding;
for( Object taskflowExeBinding : dcTaskFlowBinding.getExecutableBindings() ) {
isDirty = isTransDirty(taskflowExeBinding);
if(isDirty){
return isDirty;
}else if(exeBinding instanceof JUFormBinding){
JUFormBinding jUFormBinding = (JUFormBinding) exeBinding;
for( Object juFormIterBind : jUFormBinding.getIterBindingList() ) {
isDirty = isTransDirty(juFormIterBind);
if(isDirty){
return isDirty;
for( Object juFormExeBinding : jUFormBinding.getExecutableBindings() ) {
isDirty = isTransDirty(juFormExeBinding);
if(isDirty){
return isDirty;
}catch(Exception e){
e.printStackTrace();
return false;
}

Errors using weblogic sql driver: "No JDBC connection can be made because the transaction state is marked rollback"

One of our customers starts to encounter this error message recently.
We checked our log files. It seems that the error happens when
to obtain a jdbc connection. Have anyone seen similar problems
and knows how to fix it? thanks in advance.
We are using weblogic server 6.1sp2, and weblogic sql type 4 driver.
The functions that invoke the jdbc calls are stateless session bean
methods with their transaction attributes marked as Required.
There is no nested calls of these methods.
A partial stack trace we obtained is as following:
java.sql.SQLException: No JDBC connection can be made
because the transaction state is
Marked Rollback
     at weblogic.jdbc.jts.Connection.getOrCreateConnection(Connection.java:586)
     at weblogic.jdbc.jts.Connection.prepareStatement(Connection.java:115)
     at weblogic.jdbc.rmi.internal.ConnectionImpl.prepareStatement(ConnectionImpl.java:135)
     at weblogic.jdbc.rmi.SerialConnection.prepareStatement(SerialConnection.java:76)
lixin

Joseph Weinstein <[email protected]> wrote:
>
>
YuanHui Liu wrote:
Joe,
We got the exact same error message. The error came after we got theJDBC connection,
and trying to create statement off it.
It occurs intermitently when we are running another standalone JAVAapp to do
some end of day work, which results in the DB Server being very busy(90+%CPU
usage) for about 5 minutes. We see a surge of requests to the WLSJDBC Connection
pool. This would sometimes result in all our subsequent DB requeststo fail and
lead to a crash.
We are using WLS6.0SP1. I do not think there's a 30 seconds wait leadingto a
connection timeout that caused this(rather it is the end effect).
Can you give us a more detailed explanation? Is there a miscommunicationbetween
our DB(Sybase12) and WLS?Hi. It looks to you like it's after you get the connection, but really
it's when the server is
gettng the pool connection. For performance/synchronization reasons we
do a clever
delay: When your code asks for a pool connection we quickly give you
the pool wrapper,
but we delay actually reserving the real underlying DBMS connection until
your first
real need for a connection, at your first JDBC call, such as createStatement()
etc.
It is while waiting for a pool connection long enough for the transaction
coordinator
to have timed you out before you ever get a chance. It's nothing to do
with the
DBMS or even JDBC, I believe. I think the weblogic server either has
too few execute-threads
and/or too few CPU cycles to do the work load.
Okay, so there's a lazy initialization of the connection.
From reading our log I believe our failur is immediate rather
than waiting for 30+ seconds(the default setting) from the DB,
the timeout occurred later as a result. At the time either because the DB Server
is very busy.
Since we are running WLS6.0 we have only one connection pool,
we have defined a max of 150 threads in the pool. While this
is happening the DB Server is being pinned by an overnight job,
but the WLS Server is not busy at all. The DB and WLS resides
on different physical boxes.
We also have a thread dump from the WLS console when we rebooted the server, it
showed that we are hanging on to the thread & jdbc
connections after these exceptions has occurred instead of releasing them, note
"16083"(~4.5 hours) seconds has passed:
142 116222 Retry rollback request for tx: 'transaction=(IdHash=2963855,Name =
[EJB UserManagerBeanImpl.signalICUserServletHeartBeat()],Xid=30643:8f3838f3709bf53d,Status=Rolling
Back. [Reason = Unknown],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since
begin=16083,seconds left=10,ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=server),SCInfo[server]=(state=active),properties=({weblogic.jdbc=t3://159.55.158.25:8005,
weblogic.transaction.name=[EJB UserManagerBeanImpl.signalICUserServletHeartBeat()]}))'
Scheduled Trigger
So I would argue this problem actually chewed up resources on the WLS server.
-Yuanhui Liu
>>
>>
Thanks.
-YuanHui Liu
Joseph Weinstein <[email protected]> wrote:
lixin wrote:
One of our customers starts to encounter this error message recently.
We checked our log files. It seems that the error happens when
to obtain a jdbc connection. Have anyone seen similar problems
and knows how to fix it? thanks in advance.
We are using weblogic server 6.1sp2, and weblogic sql type 4 driver.
The functions that invoke the jdbc calls are stateless session bean
methods with their transaction attributes marked as Required.
There is no nested calls of these methods.
A partial stack trace we obtained is as following:
java.sql.SQLException: No JDBC connection can be made
because the transaction state is
Marked Rollback
at weblogic.jdbc.jts.Connection.getOrCreateConnection(Connection.java:586)Hi. This sounds like a JVM thread starvation issue, and/or a server
load
issue. What is
happening is that the transaction is started, and times out beforethe
SSB even gets to
the first JDBC work. I would first verify that the customer is using
the very latest JVM
available for the machine.
Joe Weinstein
at weblogic.jdbc.jts.Connection.prepareStatement(Connection.java:115)
at weblogic.jdbc.rmi.internal.ConnectionImpl.prepareStatement(ConnectionImpl.java:135)
at weblogic.jdbc.rmi.SerialConnection.prepareStatement(SerialConnection.java:76)
lixin

Invalid transaction state when using CMR

I've code a method which involves CMR in CMP. It's a many to many relationship. Initially I was using JBoss 4 which supports EJB 2.1. Now, I'm migrating to OC4J Standalone 10.1.2 which supports only EJB 2.0. I get the error below whenever I call the method that use this CMR.
05/04/25 17:48:15 Error in bean SBFap
java.lang.IllegalStateException: Invalid transaction state, see chapter 10 of the EJB 2.0 specification
     at EBFapLocal_EBFunctionLocal_ORCollection99.checkScope(EBFapLocal_EBFunctionLocal_ORCollection99.java:54)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.ejb.ORCollection.iterator(ORCollection.java:97)
     at com.infopro.dt.app.fap.ejb.SBFap.getAllFunction(SBFap.java:343)
     at SBFapLocal_StatelessSessionBeanWrapper22.getAllFunction(SBFapLocal_StatelessSessionBeanWrapper22.java:343)
     at com.infopro.dt.app.accesscontrol.ejb.SBAccessControl.getAllFunctionsOfFap(SBAccessControl.java:427)
     at com.infopro.dt.app.accesscontrol.ejb.SBAccessControl.getUserFunction(SBAccessControl.java:407)
     at SBAccessControlRemote_StatelessSessionBeanWrapper48.getUserFunction(SBAccessControlRemote_StatelessSessionBeanWrapper48.java:1050)
     at com.infopro.dt.ui.bizdelegate.AccessControlDelegate.getUserFunction(AccessControlDelegate.java:199)
     at com.infopro.dt.ui.accesscontrol.web.LoginBean.admin_login(LoginBean.java:89)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:324)
     at com.sun.faces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:126)
     at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:72)
     at javax.faces.component.UICommand.broadcast(UICommand.java:312)
     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:267)
     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:381)
     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:75)
     at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:90)
     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
     at net.sourceforge.myfaces.custom.fileupload.MultipartFilter.doFilter(MultipartFilter.java:88)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:649)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:322)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.HttpRequestHandler.run(HttpRequestHandler.java:270)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.HttpRequestHandler.run(HttpRequestHandler.java:112)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
     at java.lang.Thread.run(Thread.java:534)Please advise on what is the problem. What is the differences in many to many replationship of CMR in EJB 2.1 compared to EJB 2.0.
Thanks in advance.

Ok, I needed to help myself and this is what I found out:
If the table already contains records, it is not enough to doresult.moveToInsertRow();but I must beresult.last();
result.moveToInsertRow();I didn't find any explanation and even the code examples from the Sun tutorial don't mention this, so I guess it's a bug occurring in my poor IT environment: DB server running mySQL 5.0.0-alpha on a P1-233-MMX w/ 64MB under WinNT4 (hey don't laugh!!^^).
Maybe this information is of use to someone having similar problems...
Greetings!
reinski

Debugging call transaction statement

hi,
I am triggering a remotely enabled function module from a webdynpro application from portal. i am debugging this process from SM50 transaction. The function module has a call transaction statement calling VA42 transaction.
I tried below options and these did not work.
I tried changing the mode in debug mode to 'A'.
I tried to complete execution of this statement in background mode only, giving a breakpoint after this statement so that i can get bdcmsgcoll table and see the details.
But at the call transaction statement, the debug operation fails and the process is end abruptly.
Please tell me whether debugging for a call transaction statement from SM50 screen is possible and how?
Thanks in advance,
Padmini
Message was edited by:
Padmini Manickaraj

If this is a custom code, modify it to write the contents of the internal table of type BDCMSGCOLL to a file in the unix system (the files that you can view using transaction AL11). The error message will probably give you an idea as to why the BDC has failed. Make sure that this piece of code should be executable only by you. This is just for debugging. You can remove this code after you have finished analysing it.
IF sy-uname EQ <your user id>.
...code to transfer data to the unix file
endif.

ISDN doesn't change to state up - only after reboot

Hi,
i've a router 2801 with the card VIC2-2BRI, i've this problem:
when i plug-in in ISDN cable on the BRI interface the interface BRI doesn't change the state to up, it seems that the cable is not connected.
I need to reboot my router with the ISDN cable plugged in, and when the router starts, the BRI interface is active.
anybody know how to solve this problem?
This is my ISDN bri configuration:
network-clock-participate wic 3
interface BRI0/3/0
no ip address
isdn switch-type basic-net3
isdn point-to-point-setup
isdn incoming-voice voice
isdn bind-l3 ccm-manager service mgcp
isdn sending-complete
voice-port 0/3/0
output attenuation 10
echo-cancel coverage 32
no vad
compand-type a-law
cptone IT
it use MGCP protocol to comunicate with my callmanager.
thanks in advance,
Claudio.

Try:
http://www.cisco.com/warp/public/793/access_dial/ddr_dialer_profile.html
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_fix/800/800swcfg/provisio.htm

No JDBC connection can be made (transaction state is Committing)

Hi. This seems to be a case where your EJB transaction has obtained a jts
JDBC connection, but done no JDBC at all by the time the transaction is committing.
Is this possible? Nevertheless our EJB code is calling commit on on the jts
connection. Any first JDBC call on a jts connection is the one which actually
obtains the underlying pool connection, but this is being disallowed because
the tx is already being committed. I remember this being fixed a while ago,
so this may be a regression. Do file an official tech support case. Meanwhile,
I'll look into it.
Joe
Chetan Desai wrote:
>
Even we get these messages after a while the WL server is up and running. We are
using ver.6.1
Any help/suggestions?
-Chetan.
Joseph Weinstein <[email protected]> wrote:
Hi Roman. What version of our product are you using?
Joe
Roman Puttkammer wrote:
after some (presumably unrelated?) code changes, the weblogic server
seems to be
unable to open a connection to the database while calling an EJB method.
Even though
previously established connections already exist.
The exact error message text is
java.sql.SQLException: No JDBC connection can be made because the
transaction
state is Committing
The complete stack trace follows below. Does anybody have an idea what
we're
doing wrong?
any help is appreciated!
roman
java.sql.SQLException: No JDBC connection can be made because the
transaction state is Committing
at
weblogic.jdbcbase.jts.Connection.openConnectionIfNecessary(Connection.java:536)
at weblogic.jdbcbase.jts.Connection.commit(Connection.java:465)
at
weblogic.jdbcbase.jts.TxConnection.commitOnePhase(TxConnection.java:53)
at
weblogic.jts.internal.CoordinatorImpl.commitSecondPhase(CoordinatorImpl.java:403)
at
weblogic.jts.internal.CoordinatorImpl.commit(CoordinatorImpl.java:306)
at weblogic.jts.internal.TxContext.commit(TxContext.java:228)
at
weblogic.ejb.internal.StatefulEJBObject.postInvokeOurTx(StatefulEJBObject.java:204)
at
weblogic.ejb.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:285)
at
com.multex.EJB.security.ListedSecurityEJBEOImpl.getSecurityTypeCode(ListedSecurityEJBEOImpl.java:198)
at
com.multex.EJB.security.FinancialInstrumentFacade.getSecurityTypeCode(FinancialInstrumentFacade.java:88)
at
com.multex.beans.security.FinancialInstrumentFunctorBuilder.createFinancialInstrumentFunctor(FinancialInstrumentFunctorBuilder.ja
va:43)
at
com.multex.beans.security.FinancialInstrumentFunctorBuilder.createFinancialInstrumentFunctor(FinancialInstrumentFunctorBuilder.ja
va:73)
at
com.multex.beans.portfolio.HoldingFunctorBuilder.createHoldingFunctor(HoldingFunctorBuilder.java:86)
at
com.multex.beans.portfolio.HoldingFunctorBuilder.createHoldingFunctors(HoldingFunctorBuilder.java:140)
at
com.multex.beans.portfolio.AccountFunctorBuilder.setUpHoldingFunctors(AccountFunctorBuilder.java:46)
at
com.multex.beans.portfolio.AccountFunctorBuilder.createAccountFunctor(AccountFunctorBuilder.java:67)
at
com.multex.beans.portfolio.AccountFunctorBuilder.createAccountFunctors(AccountFunctorBuilder.java:93)
at
com.multex.beans.portfolio.PortfolioFunctorBuilder.setUpAccountFunctors(PortfolioFunctorBuilder.java:78)
at
com.multex.beans.portfolio.PortfolioFunctorBuilder.createPortfolioFunctor(PortfolioFunctorBuilder.java:100)
at
com.multex.beans.portfolio.PortfolioFunctorBuilder.createPortfolioFunctors(PortfolioFunctorBuilder.java:61)
at
com.multex.beans.portfolio.PortfolioUserFunctorBuilder.createPortfolioUserFunctor(PortfolioUserFunctorBuilder.java:90)
at
com.multex.beans.portfolio.PortfolioApp.createPortfolioUserFunctor(PortfolioApp.java:208)
at
com.multex.beans.portfolio.PortfolioApp.setUserId(PortfolioApp.java:41)
at
com.multex.beans.portfolio.MinPortfolioApp.setUserId(MinPortfolioApp.java:94)
at
com.multex.beans.session.UserSession.init(UserSession.java:168)
at
com.multex.beans.session.UserSession.<init>(UserSession.java:51)
at
com.multex.EJB.session.UserSessionEJB.createSession(UserSessionEJB.java:226)
at
com.multex.EJB.session.UserSessionEJB.ejbLoad(UserSessionEJB.java:157)
at
weblogic.ejb.internal.EntityEJBContext.load(EntityEJBContext.java:130)
at
weblogic.ejb.internal.EntityEJBContext.afterBegin(EntityEJBContext.java:165)
at
weblogic.ejb.internal.StatefulEJBObject.getContextForInvoke(StatefulEJBObject.java:115)
at
weblogic.ejb.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:174)
at
com.multex.EJB.session.UserSessionEJBEOImpl.isNew(UserSessionEJBEOImpl.java:196)
at
com.multex.EJB.session.UserSessionFacadeEJB.isNew(UserSessionFacadeEJB.java:128)
at com.multex.servlets.session.Servlet.doGet(Servlet.java:158)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:715)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:75)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:286)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:238)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:501)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:260)
at weblogic.t3.srvr.ExecuteThread.run(ExecuteThread.java:106)--
The Weblogic Application Server from BEA
JavaWorld Editor's Choice Award: Best Web Application Server
Java Developer's Journal Editor's Choice Award: Best Web Application
Server
Crossroads A-List Award: Rapid Application Development Tools for
Java
Intelligent Enterprise RealWare: Best Application Using a Component Architecture
http://weblogic.beasys.com/press/awards/index.htm

CLI0116E Invalid transaction state

Using IBM DB2 7.2 Type 4 driver with kodo 2.5.3
( same source code, same configuration, if swich to type 3 driver, no
exception but performance drops )
<config-property>
<config-property-name>ConnectionDriverName</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>COM.ibm.db2.jdbc.app.DB2Driver</config-property-value>
</config-property>
<config-property>
<config-property-name>ConnectionRetainMode</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>transaction</config-property-value>
</config-property>
Receiving exception every time closing PM
08:47:32,777 WARN [JDBC] [ C:null; T:20911989; D:32017535 ] exception
when closing connection
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0116E Invalid
transaction state. SQLSTATE=25000
at
COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(SQLExceptionGenerator.java:183)
at
COM.ibm.db2.jdbc.app.SQLExceptionGenerator.check_return_code(SQLExceptionGenerator.java:428)
at
COM.ibm.db2.jdbc.app.DB2Connection.close2(DB2Connection.java:846)
at COM.ibm.db2.jdbc.app.DB2Connection.close(DB2Connection.java:812)
at
com.solarmetric.datasource.ConnectionWrapper.close(ConnectionWrapper.java:288)
at
com.solarmetric.datasource.DataSourceImpl$AbstractPool.close(DataSourceImpl.java:769)
at
com.solarmetric.datasource.DataSourceImpl.close(DataSourceImpl.java:398)
at
com.solarmetric.datasource.DataSourceImpl.close(DataSourceImpl.java:372)
at
com.solarmetric.datasource.PoolConnection.close(PoolConnection.java:70)
at
com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.close(SQLExecutionManagerImpl.java:832)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.release(JDBCStoreManager.java:877)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.release(JDBCStoreManager.java:842)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.releaseDatastoreConnection(JDBCStoreManager.java:298)
at
com.solarmetric.kodo.runtime.datacache.DataCacheStoreManager.releaseDatastoreConnection(DataCacheStoreManager.java:471)
at
com.solarmetric.kodo.runtime.datacache.DataCacheStoreManager.load(DataCacheStoreManager.java:656)
at
com.solarmetric.kodo.runtime.StateManagerImpl.loadField(StateManagerImpl.java:2248)
at
com.solarmetric.kodo.runtime.StateManagerImpl.isLoaded(StateManagerImpl.java:899)
at
com.stercomm.UPCAP.biztier.persistence.ProposalPriceObjectDAO.jdoGetsalesManager(ProposalPriceObjectDAO.java)
at
com.stercomm.UPCAP.biztier.persistence.ProposalPriceObjectDAO.getSalesManager(ProposalPriceObjectDAO.java:400)
at
com.stercomm.UPCAP.biztier.ejb.impl.ProposalBean.getProposalDetails(ProposalBean.java:3186)
at sun.reflect.GeneratedMethodAccessor297.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:660)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:210)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:98)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)
at
org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313)
at org.jboss.ejb.Container.invoke(Container.java:738)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:383)
at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:536)

Zhiqiang-
If you increase your MaxPool size to something high, does this still
happen? If you use JBoss' own DataSource, does it happen?
In article <[email protected]>, Zhiqiang wrote:
The system locks on some tables after a while. -- can not search/update
The App server is JBOSS 3.0.7
Marc Prud'hommeaux wrote:
Zhiqiang-
Odd, I haven't seen that one before. However, since this is just a
warning message, you should be able to ignore it (you can decrease the
logging verbosity of the JDBC channel if you don't want to see it). The
error shouldn't cause any serious problems; if you are seeing bad
behavior because of it, please let us know.
Also, I bet that increasing your MaxSize for the connection pool will
help reduce the frequency in which this occurs (since it only looks like
it is happening when the connection is getting booted out of the pool).
In article <[email protected]>, Zhiqiang wrote:
Using IBM DB2 7.2 Type 4 driver with kodo 2.5.3
( same source code, same configuration, if swich to type 3 driver, no
exception but performance drops )
<config-property>
<config-property-name>ConnectionDriverName</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>COM.ibm.db2.jdbc.app.DB2Driver</config-property-value>
</config-property>
<config-property>
<config-property-name>ConnectionRetainMode</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>transaction</config-property-value>
</config-property>
Receiving exception every time closing PM
08:47:32,777 WARN [JDBC] [ C:null; T:20911989; D:32017535 ] exception
when closing connection
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0116E Invalid
transaction state. SQLSTATE=25000
at
COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(SQLExceptionGenerator.java:183)
at
COM.ibm.db2.jdbc.app.SQLExceptionGenerator.check_return_code(SQLExceptionGenerator.java:428)
at
COM.ibm.db2.jdbc.app.DB2Connection.close2(DB2Connection.java:846)
at COM.ibm.db2.jdbc.app.DB2Connection.close(DB2Connection.java:812)
at
com.solarmetric.datasource.ConnectionWrapper.close(ConnectionWrapper.java:288)
at
com.solarmetric.datasource.DataSourceImpl$AbstractPool.close(DataSourceImpl.java:769)
at
com.solarmetric.datasource.DataSourceImpl.close(DataSourceImpl.java:398)
at
com.solarmetric.datasource.DataSourceImpl.close(DataSourceImpl.java:372)
at
com.solarmetric.datasource.PoolConnection.close(PoolConnection.java:70)
at
com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.close(SQLExecutionManagerImpl.java:832)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.release(JDBCStoreManager.java:877)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.release(JDBCStoreManager.java:842)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.releaseDatastoreConnection(JDBCStoreManager.java:298)
at
com.solarmetric.kodo.runtime.datacache.DataCacheStoreManager.releaseDatastoreConnection(DataCacheStoreManager.java:471)
at
com.solarmetric.kodo.runtime.datacache.DataCacheStoreManager.load(DataCacheStoreManager.java:656)
at
com.solarmetric.kodo.runtime.StateManagerImpl.loadField(StateManagerImpl.java:2248)
at
com.solarmetric.kodo.runtime.StateManagerImpl.isLoaded(StateManagerImpl.java:899)
at
com.stercomm.UPCAP.biztier.persistence.ProposalPriceObjectDAO.jdoGetsalesManager(ProposalPriceObjectDAO.java)
at
com.stercomm.UPCAP.biztier.persistence.ProposalPriceObjectDAO.getSalesManager(ProposalPriceObjectDAO.java:400)
at
com.stercomm.UPCAP.biztier.ejb.impl.ProposalBean.getProposalDetails(ProposalBean.java:3186)
at sun.reflect.GeneratedMethodAccessor297.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:660)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:210)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:98)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)
at
org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313)
at org.jboss.ejb.Container.invoke(Container.java:738)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:383)
at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:536)
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com

Open MQ 4.3 "Bad transaction state transition"

We have Open MQ 4.3 in remote, enhanced cluster. We are seeing ERRORs and WARNINGs in broker log file. They occur sporadically, once every couple hours or so. I think they might be related. Anyone have an idea what the problems may be?
1) "Bad transaction state transition"
[30/Jun/2009:00:48:12 EDT] ERROR com.sun.messaging.jmq.jmsserver.util.BrokerException: Bad transaction state transition. Cannot perform operation PREPARE_TRANSACTION(56) (XAFlag=null) on a transaction in state STARTED(1).: TUID=8284690576893811200 Xid=62726970706C303130302E6263627372692E6F72672C7365727665722C5032363137332C00E11C0000CD99242E62726970706C303130302E6263627372692E6F72672C7365727665722C503236313733:
com.sun.messaging.jmq.jmsserver.util.BrokerException: Bad transaction state transition. Cannot perform operation PREPARE_TRANSACTION(56) (XAFlag=null) on a transaction in state STARTED(1).
at com.sun.messaging.jmq.jmsserver.data.TransactionState.nextState(TransactionState.java:440)
at com.sun.messaging.jmq.jmsserver.data.handlers.TransactionHandler.doPrepare(TransactionHandler.java:1625)
at com.sun.messaging.jmq.jmsserver.data.handlers.TransactionHandler.handle(TransactionHandler.java:551)
at com.sun.messaging.jmq.jmsserver.data.PacketRouter.handleMessage(PacketRouter.java:181)
at com.sun.messaging.jmq.jmsserver.service.imq.IMQIPConnection.readData(IMQIPConnection.java:1489)
at com.sun.messaging.jmq.jmsserver.service.imq.IMQIPConnection.process(IMQIPConnection.java:644)
at com.sun.messaging.jmq.jmsserver.service.imq.OperationRunnable.process(OperationRunnable.java:170)
at com.sun.messaging.jmq.jmsserver.util.pool.BasicRunnable.run(BasicRunnable.java:493)
at java.lang.Thread.run(Thread.java:595)
2) "ROLLBACK_TRANSACTION(48): Ignoring unknown XID"
[29/Jun/2009:22:54:34 EDT] WARNING ROLLBACK_TRANSACTION(48): Ignoring unknown XID=62726970706C303130302E6263627372692E6F72672C7365727665722C5032363137332C0006140000CD99242E62726970706C303130302E6263627372692E6F72672C7365727665722C503236313733 broker will notify the client
3) "Heartbeat timeout"
[29/Jun/2009:22:54:14 EDT] WARNING [B2122]: Heartbeat timeout from /192.168.106.192:32000 [brokerID=jmsnode_brippl0301, brokerSession=8155493556708599552] (seq#=7856, ts=1246330447089, interval=2, len=231) sender=/192.168.106.192:57964
Steve

Your question has also been posted to mq-interest alias with broker/appserver log files. The following is based on the log files:
1) "Bad transaction state transition"
The server.log you provided shows that right before this exception, there was appserver exception as below. It appears that something was wrong with the application/appserver state:
[#|2009-06-29T19:03:32.253-0400|WARNING|sun-appserver9.1|javax.enterprise.system.core.transaction|_ThreadID=22;_ThreadName=JMSJCA sync #0(queRouterRequest);Context=RouterJMS_ESB_R1_0032_PPMO_090626/queRouterRequest_svcBpRouterJMS_ejb;_RequestID=f92d8d20-1abb-4c0b-b6eb-cd205eabcd37;|JTS5041: The resource manager is doing work outside a global transaction
javax.transaction.xa.XAException
2) "ROLLBACK_TRANSACTION(48): Ignoring unknown XID"
This can be ignored. By looking at a couple of such WARNING messages in the broker log you provided
- The transaction was cleaned up on client connection closing and then the client reconnects, appserver attempts to rollback the old transaction.
3) "Heartbeat timeout"
This will be logged if the broker didn't receive heartbeat from the other broker for configured timeout period. This can happen occasionally due to network fluctuation. The heartbeat timeout values can be adjusted by broker "Failure Detection Properties"
http://docs.sun.com/app/docs/doc/820-6740/gguju?a=view

If statement doesn't affect for loop

I wrote a function within a function to control 2 Tweens.
(the 2nd one isnt in the function, it's called)
My problem is... is that it works for the first time.. the button is hovered over and all the other buttons show themselves and then disappear again, except the one you're over. Then I do it a 2nd time and it doesn't work. why is it only working right one time? and why isn't the if statement I put in the local function affecting the for loop? The 2nd time it takes the button you're hovering over with it and fades it out. (even though the if statement registers according to trace)
this is the code
import fl.transitions.Tween;
import fl.transitions.easing.*;
var shortInst:Array = [btn1, btn2, btn3, exit];
var objTween:Tween;
function mouseOff(e:Event):void {
     if (e.currentTarget.alpha !== 0) {
          objTween = new Tween(e.currentTarget, "alpha", None.easeOut, 1, 0, 0.25, true);
var eTimer:Timer = new Timer(3000, 1); //timer that only runs once (in ms)
function navFX(e:Event):void {
     for (var i:Number = 0; i < shortInst.length; i++) {
          objTween = new Tween(shortInst[i], "alpha", None.easeOut, 0, 1, 0.25, true);
          eTimer.addEventListener(TimerEvent.TIMER, local);
          eTimer.start();
          function local(t:TimerEvent):void {
               trace("e.target in local func: " + e.target);
               for (var i:Number = 0; i < shortInst.length; i++) {
                    if (shortInst[i] !== e.target) {
                    shortInst[i].dispatchEvent(new Event(MouseEvent.MOUSE_OUT));

is this what you want?
import fl.transitions.Tween;
import fl.transitions.easing.*;
var shortInst:Array = [btn1,btn2,btn3,exit];
var objTween:Tween;
function mouseOff(e:Event):void
if (e.currentTarget.alpha !== 0)
objTween = new Tween(e.currentTarget,"alpha",None.easeOut,1,0,0.25,true);
function navFX(e:Event):void
var eTimer:Timer = new Timer(3000,1); // <- moved that line here
for (var i:Number = 0; i < shortInst.length; i++)
objTween = new Tween(shortInst[i],"alpha",None.easeOut,0,1,0.25,true);
eTimer.addEventListener(TimerEvent.TIMER, local);
eTimer.start();
function local(t:TimerEvent):void
trace("e.target in local func: " + e.target);
for (var i:Number = 0; i < shortInst.length; i++)
   if (shortInst[i] !== e.target)
    shortInst[i].dispatchEvent(new Event(MouseEvent.MOUSE_OUT));
for (var i:Number = 0; i < shortInst.length; i++)
shortInst[i].alpha = 0;
shortInst[i].addEventListener(MouseEvent.MOUSE_OVER, navFX);
shortInst[i].addEventListener(MouseEvent.MOUSE_OUT, mouseOff);

Transaction STAT is not in SAP ECC 6.0

Hello,
Do you know what new transaction replaced the STAT transaction??
Exist the STAD but that only tells by 1 day... not a range day as STAT did...

Hi,
The alternative tcode is ST03n or STAD.
Please go through the following lnks -
T code that are changes in an upgrade from R3 4.6c to ECC6
https://wiki.sdn.sap.com/wiki/display/ERP6/TransactionsChangedinECC6.0
Thanks,
Nitesh Jain

Sp_executesql vs transaction statement within Stored Procedure

Experts,
Any difference between sp_executesql vs Transaction/Commit statement or try/catch block within Stored Procedure?
What is the best practice to use and why?
Thank You
Regards,
Kumar
Please do let us know your feedback. Thank You - KG, MCTS

Your question is a bit strange. sp_executesql is used for dynamic SQL. Unless the problem demands dynamic SQL and, therefore, sp_executesql, there is no need to use it.
For a single statement I would not use transaction and try/catch. For multiple statements you do need to use transaction. It's up to you if you want to use try/catch in the SP or not and trap the error in the client application.
For every expert, there is an equal and opposite expert. - Becker's Law
My blog
My TechNet articles

RAC and instance goes down, transaction state?

I was talking to our physical DBAs, and they told me that when the RAC node you're connected to goes down:
1) if you're mid-query, your process gets transferred to another node
2) if you're not currently running a query, but you are in the middle of a transaction (ie no rollback or commit), that you lose the state of your transaction
I've seen 1) in action, but I haven't heard anything like 2). Is it true? They couldn't remember if they'd read it in the manuals, but they had heard it mentioned on more than 1 occasion during demonstrations.
-Chuck

What version of Oracle?
What kind of Application?
For most of the history of OPS/RAC if you are connected to an instance in the middle of a transaction or not when the instance you are connected to dies you must reconnect. Only if an Oranet fail-over connection was configured could you successfully reconnet asking for the same instance, though you would actually be connected to one of the available instances.
Any work in process was rolled back by another node.
Only with the advent of automatic transaction failover, ATF, would work on the dieing instance transfer to another instance. This works only if the application is coded to perform this task and when it first came out only for Select statements.
HTH -- Mark D Powell --

SetAttribute() doesn't affect transaction state

Similar Messages

Maybe you are looking for