Transaction not rolling back in stateless session bean
Hi,
I am facing a problem...
I have one stateless session bean which does multiple updates in SYBASE database.I
am using non-transactional datasource. Bean calls a method of data access obejct
whcih internally calls more than one one mehtod to update different tables.If
any of update fails then I am explicitly thorwing EJBException. Still it is not
rolling back.
I have one more application where similar situation is there but only difference
is that there we have Entity bean and updates are being done through store method.
In that case with same datasource it is rolling back perfectly.
I have tried with transactional datasource as well but it didn't work.Then I tried
to put setAutoCommit(false) in my connection class which gives me connection.But
then it is not allowing me to enter into my application.
In deployment descriptor for both the beans transaction attribute is required
for all methods.
Regards.
Rahul.
Hi,
I am facing a problem...
I have one stateless session bean which does multiple updates in SYBASE database.I
am using non-transactional datasource. Bean calls a method of data access obejct
whcih internally calls more than one one mehtod to update different tables.If
any of update fails then I am explicitly thorwing EJBException. Still it is not
rolling back.
I have one more application where similar situation is there but only difference
is that there we have Entity bean and updates are being done through store method.
In that case with same datasource it is rolling back perfectly.
I have tried with transactional datasource as well but it didn't work.Then I tried
to put setAutoCommit(false) in my connection class which gives me connection.But
then it is not allowing me to enter into my application.
In deployment descriptor for both the beans transaction attribute is required
for all methods.
Regards.
Rahul.
Similar Messages
-
Transaction is not Rolling Back in Stateless Session Bean
Hi,
I am using UserTransaction in Stateless Session bean .
Transaction is not rolling back.
The following code is writen in stateless session bean. In UserTransaction i am
calling Two methods of another stateless session bean.
The problem is if doJob2() method fails, doJob1() method is rolling back. These
two methods consist of SQL statement with different Connection Object from TXDataSource.And
session bean(TestSession) is set to CMT, attribute as "Required".
try{
Context ictx=new InitialContext();
TestHome home=(TestHome)ictx.lookup("TestSession");
utx = sessionCtx.getUserTransaction();
utx.begin();
TestRemote remote=home.create();
remote.doJob1();
remote.doJob2();
utx.commit();
}catch(Exception e)
try{
utx.rollback();
}catch(Exception ex)
System.out.println("unable to rollback"+ex);
if any SQL Exception as occured in doJob2(), its calling method utx.rollback()
in catch block. but SQL statements executed thru. doJob1() are not rolling back.
what might be the reason?
thanks
Ranganath
Thanx Priscilla ,
Transaction is working.
ranganath
"Priscilla Fung" <[email protected]> wrote:
>
>In your ejb-jar.xml, you should specify <transaction-type> element to
>be "Container"
>for container-managed transaction. If you specified it to be "Bean" for
>bean-managed
>transaction, EJB ontainer will suspend the caller's transaction before
>starting
>a new transaction for your doJobX() methods. Thus, doJob1()nd doJob2()
>will be
>executing in different transactions, and thus rolling back doJob2()'s
>transaction
>will have no effect on work done and committed in doJob1()'s transaction.
>
>Regards,
>
>Priscilla
>
>
>"Ranganath" <[email protected]> wrote:
>>
>>
>>
>>I am sending config.xml,deployment descriptors, code snippet for TestSession.
>>i
>>am using weblogic6.0sp2.
>>if you need any aditional info. please let me know.
>>
>>thanks
>>ranganath
>>
>>EJB-JAR.xml
>>
>><?xml version="1.0"?>
>>
>><!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
>JavaBeans
>>1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'>
>>
>><ejb-jar>
>> <enterprise-beans>
>> <session>
>> <ejb-name>TestSession</ejb-name>
>> <home>com.apar.sslbridge.test.TestHome</home>
>> <remote>com.apar.sslbridge.test.TestRemote</remote>
>> <ejb-class>com.apar.sslbridge.test.TestBean</ejb-class>
>> <session-type>Stateless</session-type>
>> <transaction-type>Bean</transaction-type>
>> <resource-ref>
>> <res-ref-name>jdbc/oraclePool</res-ref-name>
>> <res-type>javax.sql.DataSource</res-type>
>> <res-auth>Container</res-auth>
>> </resource-ref>
>> </session>
>> </enterprise-beans>
>> <assembly-descriptor>
>> <container-transaction>
>> <method>
>> <ejb-name>TestSession</ejb-name>
>> <method-intf>Remote</method-intf>
>> <method-name>*</method-name>
>> </method>
>> <trans-attribute>Required</trans-attribute>
>> </container-transaction>
>> </assembly-descriptor>
>></ejb-jar>
>>
>>
>>TestSession CODE:
>>
>>
>> public void doJob1() throws RemoteException
>> {
>> Statement st = null;
>> String query=null;
>> try{
>> con=getConnection();
>> st=con.createStatement();
>> query="insert into x values("+x+++")";
>> System.out.println(query);
>> int rec=st.executeUpdate(query);
>> }catch(SQLException sqle)
>> {
>> System.out.println("SQL Exception "+sqle);
>> throw new RemoteException("RemoteException*****SQLError");
>> } catch (Exception e) {
>> System.out.println("Exception "+e);
>> throw new RemoteException("RemoteException*****GenralError");
>> }
>>}
>>
>>
>> public void doJob2()throws RemoteException
>> {
>> Connection con=null;
>> Statement st = null;
>> String query=null;
>> try{
>> con=getConnection();
>> st=con.createStatement();
>> query="insert into y values("+x+++")";
>> System.out.println(query);
>> int rec=st.executeUpdate(query);
>> }catch(SQLException sqle)
>> {
>> System.out.println("SQL Exception "+sqle);
>> throw new RemoteException("RemoteException*****SQLError");
>> } catch (Exception e) {
>> System.out.println("Exception "+e);
>> throw new RemoteException("RemoteException*****GenralError");
>>}
>>}
>>private Connection getConnection(){
>>try {
>>Connection con = StaticParams.POOL_DATASOURCE.getConnection();
>>return con;
>> } catch(Exception e) {
>> System.out.println("TestBean.getConnection() Unable to get get pool
>>connection
>>" + e);
>> }
>>}
>>
>>
>>
>>
>>"Priscilla Fung" <[email protected]> wrote:
>>>
>>>It should work if you are using TxDataSource. Could you post your
>config.xml,
>>>deployment descriptors, code snippet for TestSession?
>>>
>>>Regards,
>>>
>>>Priscilla
>>>
>>>"Ranganath" <[email protected]> wrote:
>>>>
>>>>Hi,
>>>>
>>>> I am using UserTransaction in Stateless Session bean .
>>>> Transaction is not rolling back.
>>>>
>>>>The following code is writen in stateless session bean. In UserTransaction
>>>>i am
>>>>calling Two methods of another stateless session bean.
>>>> The problem is if doJob2() method fails, doJob1() method is rolling
>>>> back. These
>>>>two methods consist of SQL statement with different Connection Object
>>>>from TXDataSource.And
>>>>session bean(TestSession) is set to CMT, attribute as "Required".
>>>>
>>>> try{
>>>> Context ictx=new InitialContext();
>>>> TestHome home=(TestHome)ictx.lookup("TestSession");
>>>> utx = sessionCtx.getUserTransaction();
>>>> utx.begin();
>>>> TestRemote remote=home.create();
>>>> remote.doJob1();
>>>> remote.doJob2();
>>>> utx.commit();
>>>> }catch(Exception e)
>>>> {
>>>> try{
>>>> utx.rollback();
>>>> }catch(Exception ex)
>>>> {
>>>> System.out.println("unable to rollback"+ex);
>>>> }
>>>> }
>>>>if any SQL Exception as occured in doJob2(), its calling method utx.rollback()
>>>>in catch block. but SQL statements executed thru. doJob1() are not
>>rolling
>>>>back.
>>>>what might be the reason?
>>>>
>>>>thanks
>>>>Ranganath
>>>
>>
>
-
Stateless SessionBean Transaction not Rolling Back
I have a situation to create two Entity Beans within a single Transaction,
so I created a Session Bean to create the two Entity Beans.
I have the Session bean with attribute
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
And 2 Entity beans with attributes:
<persistence-type>Container</persistence-type>
<trans-attribute>Required</trans-attribute>
Inside the Session Bean I have a method which calls the create on the two
Entity Beans.
create ContactInfo(){
Phone ph = phoneHome.Create(phoneData);
Address ad = addressHome.Create(addressData);
When the secound bean fails to create (Key voilation), my transaction is not
getting rolled back.
The Phone Create did not roll back eventhough the address create failed.
Please give me some suggetion which transaction attributes to use
I am using Weblogic 6.0
For Create Exceptions , the transactions may or may not rollback. Mostly it
wont rollback. You have to set the sessionctx.setRollbackOnly() to mark it
for rollback in the catch block of the Create Exception.
Regards,
Swaminathan K.N.
santo comar <[email protected]> wrote in message
news:3b8dbb61$[email protected]..
> I have a situation to create two Entity Beans within a single Transaction,
> so I created a Session Bean to create the two Entity Beans.
>
> I have the Session bean with attribute
>
> <session-type>Stateless</session-type>
> <transaction-type>Container</transaction-type>
>
> And 2 Entity beans with attributes:
>
> <persistence-type>Container</persistence-type>
> <trans-attribute>Required</trans-attribute>
>
> Inside the Session Bean I have a method which calls the create on the two
> Entity Beans.
>
> create ContactInfo(){
> Phone ph = phoneHome.Create(phoneData);
> Address ad = addressHome.Create(addressData);
> }
>
> When the secound bean fails to create (Key voilation), my transaction is
not
> getting rolled back.
> The Phone Create did not roll back eventhough the address create failed.
> Please give me some suggetion which transaction attributes to use
>
> I am using Weblogic 6.0
>
>
>
-
Configuration:
- WLS 5.10 SP8
- Oracle 8.1.6
- TX DataSource connected to a Connection pool of oracle JDBC connections
I have a stateless session with a method register() that performs three insert operations in the oracle database via a connection fetched from tha TX Datasource object.
The method register has been marked with the transaction attribute required.
I recieve a SQLException from Oracle when trying to insert in one of the three tables and want to rollback the transaction.
I have tried to use setRollBackOnly(), throw an EJB exception
and i get the following message from WLS:
java.sql.SQLException: ORA-00001: unique constraint (ISACOWN.UK_ISIS_REFERENCE2) violated
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:114)
at oracle.jdbc.oci8.OCIDBAccess.check_error(OCIDBAccess.java, Compiled Code)
at oracle.jdbc.oci8.OCIDBAccess.executeFetch(OCIDBAccess.java, Compiled Code)
at oracle.jdbc.oci8.OCIDBAccess.parseExecuteFetch(OCIDBAccess.java:1235)
at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java, Compiled Code)
at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1232)
at oracle.jdbc.driver.OracleStatement.doExecuteWithBatch(OracleStatement.java:1353)
at oracle.jdbc.driver.OracleStatement.doExecute(OracleStatement.java, Compiled Code)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java, Compiled Code)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java, Compiled Code)
at weblogic.jdbc20.pool.PreparedStatement.executeUpdate(PreparedStatement.java:47)
at weblogic.jdbc20.rmi.internal.PreparedStatementImpl.executeUpdate(PreparedStatementImpl.java:54)
at weblogic.jdbc20.rmi.SerialPreparedStatement.executeUpdate(SerialPreparedStatement.java:55)
at net.astrazeneca.cmi.data.Crud.execDML(Crud.java:283)
at net.astrazeneca.cmi.data.dao.MolStructDAO.insertIsisRef(MolStructDAO.java:136)
at net.astrazeneca.cmi.data.dao.MolStructDAO.insert(MolStructDAO.java, Compiled Code)
at net.astrazeneca.cmi.data.dataservice.MolStructureDS.register(MolStructureDS.java, Compiled Code)
at net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl.register(MolStructureDSEOImpl.java, Compiled Code)
at net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl_WLSkel.invoke(MolStructureDSEOImpl_WLSkel.java, Compiled Code)
at weblogic.rmi.extensions.BasicServerObjectAdapter.invoke(BasicServerObjectAdapter.java, Compiled Code)
at weblogic.rmi.extensions.BasicRequestHandler.handleRequest(BasicRequestHandler.java, Compiled Code)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java, Compiled Code)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java, Compiled Code)
ti jan 23 11:12:20 GMT+01:00 2001:<I> <EJB JAR deployment F:\Projects\MolStructureDS\MolStructureDS.jar> Transaction: '980237619834_1326' rolled back
due to EJB exception:
javax.ejb.EJBException
at net.astrazeneca.cmi.data.dataservice.MolStructureDS.register(MolStructureDS.java, Compiled Code)
Anybody got an idea ? at net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl.register(MolStructureDSEOImpl.java, Compiled Code)
at net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl_WLSkel.invoke(MolStructureDSEOImpl_WLSkel.java, Compiled Code)
at weblogic.rmi.extensions.BasicServerObjectAdapter.invoke(BasicServerObjectAdapter.java, Compiled Code)
at weblogic.rmi.extensions.BasicRequestHandler.handleRequest(BasicRequestHandler.java, Compiled Code)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java, Compiled Code)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java, Compiled Code)
ti jan 23 11:12:20 GMT+01:00 2001:<E> <Adapter> Exception thrown by rmi server: [-3565031217135527434S157.96.215.53:[7001,7001,7002,7002,7001,-1]/466]
javax.ejb.EJBException
at net.astrazeneca.cmi.data.dataservice.MolStructureDS.register(MolStructureDS.java, Compiled Code)
at net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl.register(MolStructureDSEOImpl.java, Compiled Code)
at net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl_WLSkel.invoke(MolStructureDSEOImpl_WLSkel.java, Compiled Code)
at weblogic.rmi.extensions.BasicServerObjectAdapter.invoke(BasicServerObjectAdapter.java, Compiled Code)
at weblogic.rmi.extensions.BasicRequestHandler.handleRequest(BasicRequestHandler.java, Compiled Code)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java, Compiled Code)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java, Compiled Code)
No matter what I have tried so far the two inserts that are OK are commited in Oracle. What I want is to make all three inserts in the transaction rolled back.
Anybody got an idea ?
Yes, all through the same connection and the connection is from a TX data source in
WLS 5.1 with SP8
But.... I do NOT fetch the connection inside the transaction..but I didn't think
that was nescessery... is it ?
When I tried this and checked the JDBC log the auto-commit was turned to off and
everything worked smoothly.
/Paul
"Cameron Purdy" <[email protected]> wrote:
>All through the same connection? And the connection is from a tx data
>source? And auto-commit is off?
>
>If so, then someone is committing the transaction.
>
>Is this 5.1?
>
>--
>Cameron Purdy
>Tangosol, Inc.
>http://www.tangosol.com
>+1.617.623.5782
>WebLogic Consulting Available
>
>
>"Paul Eriksson" <[email protected]> wrote in message
>news:[email protected]...
>>
>> I've already tried this but still... the tho first inserts are commited
>and the third that causes the rollback of course is not.
>>
>> /P
>>
>> "Cameron Purdy" <[email protected]> wrote:
>> >Don't set rollback only, just throw a runtime exception (like
>EJBException).
>> >
>> >--
>> >Cameron Purdy
>> >Tangosol, Inc.
>> >http://www.tangosol.com
>> >+1.617.623.5782
>> >WebLogic Consulting Available
>> >
>> >
>> >"Paul Eriksson" <[email protected]> wrote in message
>> >news:[email protected]...
>> >>
>> >> Configuration:
>> >>
>> >> - WLS 5.10 SP8
>> >> - Oracle 8.1.6
>> >> - TX DataSource connected to a Connection pool of oracle JDBC
>connections
>> >>
>> >> I have a stateless session with a method register() that performs three
>> >insert operations in the oracle database via a connection fetched from
>tha
>> >TX Datasource object.
>> >>
>> >> The method register has been marked with the transaction attribute
>> >required.
>> >>
>> >> I recieve a SQLException from Oracle when trying to insert in one of
>the
>> >three tables and want to rollback the transaction.
>> >>
>> >>
>> >> I have tried to use setRollBackOnly(), throw an EJB exception
>> >> and i get the following message from WLS:
>> >>
>> >>
>> >> java.sql.SQLException: ORA-00001: unique constraint
>> >(ISACOWN.UK_ISIS_REFERENCE2) violated
>> >>
>> >> at
>> >oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:114)
>> >> at oracle.jdbc.oci8.OCIDBAccess.check_error(OCIDBAccess.java,
>> >Compiled Code)
>> >> at oracle.jdbc.oci8.OCIDBAccess.executeFetch(OCIDBAccess.java,
>> >Compiled Code)
>> >> at
>> >oracle.jdbc.oci8.OCIDBAccess.parseExecuteFetch(OCIDBAccess.java:1235)
>> >> at
>> >oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java,
>> >Compiled Code)
>> >> at
>>
>>oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1232
>)
>> >> at
>>
>>oracle.jdbc.driver.OracleStatement.doExecuteWithBatch(OracleStatement.java:
>1
>> >353)
>> >> at
>> >oracle.jdbc.driver.OracleStatement.doExecute(OracleStatement.java,
>Compiled
>> >Code)
>> >> at
>>
>>oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.jav
>a
>> >, Compiled Code)
>> >> at
>>
>>oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStat
>e
>> >ment.java, Compiled Code)
>> >> at
>>
>>weblogic.jdbc20.pool.PreparedStatement.executeUpdate(PreparedStatement.java
>:
>> >47)
>> >> at
>>
>>weblogic.jdbc20.rmi.internal.PreparedStatementImpl.executeUpdate(PreparedSt
>a
>> >tementImpl.java:54)
>> >> at
>>
>>weblogic.jdbc20.rmi.SerialPreparedStatement.executeUpdate(SerialPreparedSta
>t
>> >ement.java:55)
>> >> at net.astrazeneca.cmi.data.Crud.execDML(Crud.java:283)
>> >> at
>>
>>net.astrazeneca.cmi.data.dao.MolStructDAO.insertIsisRef(MolStructDAO.java:1
>3
>> >6)
>> >> at
>> >net.astrazeneca.cmi.data.dao.MolStructDAO.insert(MolStructDAO.java,
>Compiled
>> >Code)
>> >> at
>>
>>net.astrazeneca.cmi.data.dataservice.MolStructureDS.register(MolStructureDS
>..
>> >java, Compiled Code)
>> >> at
>>
>>net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl.register(MolStruc
>t
>> >ureDSEOImpl.java, Compiled Code)
>> >> at
>>
>>net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl_WLSkel.invoke(Mol
>S
>> >tructureDSEOImpl_WLSkel.java, Compiled Code)
>> >> at
>>
>>weblogic.rmi.extensions.BasicServerObjectAdapter.invoke(BasicServerObjectAd
>a
>> >pter.java, Compiled Code)
>> >> at
>>
>>weblogic.rmi.extensions.BasicRequestHandler.handleRequest(BasicRequestHandl
>e
>> >r.java, Compiled Code)
>> >> at
>>
>>weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java,
>> >Compiled Code)
>> >> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java,
>Compiled
>> >Code)
>> >> ti jan 23 11:12:20 GMT+01:00 2001:<I> <EJB JAR deployment
>> >F:\Projects\MolStructureDS\MolStructureDS.jar> Transaction:
>> >'980237619834_1326' rolled back
>> >> due to EJB exception:
>> >> javax.ejb.EJBException
>> >> at
>>
>>net.astrazeneca.cmi.data.dataservice.MolStructureDS.register(MolStructureDS
>..
>> >java, Compiled Code)
>> >>
>> >> Anybody got an idea ? at
>>
>>net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl.register(MolStruc
>t
>> >ureDSEOImpl.java, Compiled Code)
>> >> at
>>
>>net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl_WLSkel.invoke(Mol
>S
>> >tructureDSEOImpl_WLSkel.java, Compiled Code)
>> >> at
>>
>>weblogic.rmi.extensions.BasicServerObjectAdapter.invoke(BasicServerObjectAd
>a
>> >pter.java, Compiled Code)
>> >> at
>>
>>weblogic.rmi.extensions.BasicRequestHandler.handleRequest(BasicRequestHandl
>e
>> >r.java, Compiled Code)
>> >> at
>>
>>weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java,
>> >Compiled Code)
>> >> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java,
>Compiled
>> >Code)
>> >>
>> >> ti jan 23 11:12:20 GMT+01:00 2001:<E> <Adapter> Exception thrown by
>rmi
>> >server:
>> >[-3565031217135527434S157.96.215.53:[7001,7001,7002,7002,7001,-1]/466]
>> >>
>> >> javax.ejb.EJBException
>> >> at
>>
>>net.astrazeneca.cmi.data.dataservice.MolStructureDS.register(MolStructureDS
>..
>> >java, Compiled Code)
>> >> at
>>
>>net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl.register(MolStruc
>t
>> >ureDSEOImpl.java, Compiled Code)
>> >> at
>>
>>net.astrazeneca.cmi.data.dataservice.MolStructureDSEOImpl_WLSkel.invoke(Mol
>S
>> >tructureDSEOImpl_WLSkel.java, Compiled Code)
>> >> at
>>
>>weblogic.rmi.extensions.BasicServerObjectAdapter.invoke(BasicServerObjectAd
>a
>> >pter.java, Compiled Code)
>> >> at
>>
>>weblogic.rmi.extensions.BasicRequestHandler.handleRequest(BasicRequestHandl
>e
>> >r.java, Compiled Code)
>> >> at
>>
>>weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java,
>> >Compiled Code)
>> >> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java,
>Compiled
>> >Code)
>> >>
>> >>
>> >>
>> >> No matter what I have tried so far the two inserts that are OK are
>> >commited in Oracle. What I want is to make all three inserts in the
>> >transaction rolled back.
>> >>
>> >> Anybody got an idea ?
>> >
>> >
>>
>
>
-
Transaction can be applied to stateless session bean
is transaction can be applied to stateless session beanif yes/no why?
Just because a stateless session bean is stateless doesn't mean it doens't hold state. The stateless means it shouldn't hold any client state.
It can hold onto for example the dao objects.
The idea is that you pass all the client state to the sessionbean when calling it.
Eg.
public void doBulkOperation( User user ,string param1, String param2){
operation1( user, param1 );
operation2( user, param2 );
public void operation1( User user ,String param1){
//do some work involving user
public void operation2( User user ,String param2){
//do some work involving user
now suppose that doBulkOperation, operation1, operation2 are declared as transaction required. doBulkOperation starts the transaction if there isn't one running and joins the transaction. Then operation1 and operation2 join in the transaction.
Perfectly safe!
What you're not allowed to do is the following:
privata User user
public void doBulkOperation( User user ,string param1, String param2){
this.user = user;
operation1( param1 );
operation2( param2 );
public void operation1( String param1){
//do some work involving user
public void operation2( String param2){
//do some work involving user
This would be unsafe because concurrent calls will change the user and produce unpredictable results and possibly corrupting data.
It will work perfectly thougn if there is only one user or you're using a statefull session bean providing you don't share that bean with several clients. -
Transaction Management - App Module in Stateless Session Bean
Hi All,
We are using Application Module in local mode in a Stateless Session Bean. The application module gets the database connection from the datasource of the application server(Oracle 9iAS).
The problem that we are facing is as follows
- When a database update/insert is made using the Application Module and the ViewObject (and the underlying Entity Object), the changes are not being commited.
Please note that we are not using the ApplicationModule.getTransaction.commit() as it does not give us commit/rollback control from another Session Bean/UseCase. We instead are relying on the Container to manager the transaction and commit the database changes. But the container does not seem to refresh the changes to the database.
Q1 - Is there a contract between the container and the application module that needs to be created so that the container managed-transaction and the application module work together ?
Any help in this matter would be greatly appreciated.
-Ankur SinhaQ1 - Is there a contract between the container and the application module that needs to be created so that the container managed-transaction and the application module work together ?For stateless beans you have to call postChanges in the business method for the changes to be applied to the db. For stateful beans bc4j we do that automatically just before the transaction ends.
Take a look at the following howto
http://otn.oracle.com/products/jdev/howtos/bc4j/ejbstateless_with_bc4j.html
In 9.0.3 you'll be able to create a stateless service bean declaritively.
dhiraj Hi dhiraj,
- I looked at the example but was not able to find the ContainerManagedTxnHandlerImpl class in the BC4J jars. Can you point me to the latest version of BC4J on technet ?. I already have JDeveloper 9.0.2
- Regarding your response, what do you mean by creating stateless service bean declaritively ?
Thanks,
Ankur -
Container transaction NOT rolled back after a long period of time.
Hi, I am using Weblogic 6.1SP5 on RedHat 7.1 and I have seen an unexpected
behaviour with an MDB and I would like to know if there is any circumstance
in which a transaction is not rolled back automatically by the container
after the transaction timeout specified on MDB descriptor expired.
The fact is I have seen a thread locked for 3 entire days without any
exception being raised (the trans timeout was set to 900 seconds for
debugging porpouses)
Sadly I didn't thought on issuing a ps -ax and a netstat -np in order to see
if there was any connection active for any of the JVM threads.
As an aside note I had to throw a kill -9 to Weblogic's JVM in order to
completely stop it because using the standard "stopWeblogic.sh" script it
got stalled.
The only unusual thing that I can think of the MDB is doing is opening a
connection against a remote system via a socket.
My question is. Is it possible that a thread locked on I/O (in this case a
socket) to be out of control in terms of throwing at it a "Transaction
rolled back exception"?
I have modified my code in order to set SO_TIMEOUT on the socket just in
case the other peer hangs and never returns control. But I would like to
know the problem could be there.
I know for sure that at the time the thread stalled the other peer died
(exceptions on other MDBs trying to connect to remote system) but I expected
a "socket exception" to be thrown by the O.S. to the stalled thread instead
of having the thread waiting forever on that "open" socket.
Thanks in advance.
Ignacio.
While a tramsaction may be rolled back at the transaction timeout,
the thread is not stopped. The actual exception won't occur until
the MDB completes. If the MDB doesn't complete (as in this case),
you won't get the exception.
"Ignacio G. Dupont" <[email protected]> wrote in message news:[email protected]...
> Hi, I am using Weblogic 6.1SP5 on RedHat 7.1 and I have seen an unexpected
> behaviour with an MDB and I would like to know if there is any circumstance
> in which a transaction is not rolled back automatically by the container
> after the transaction timeout specified on MDB descriptor expired.
>
> The fact is I have seen a thread locked for 3 entire days without any
> exception being raised (the trans timeout was set to 900 seconds for
> debugging porpouses)
>
> Sadly I didn't thought on issuing a ps -ax and a netstat -np in order to see
> if there was any connection active for any of the JVM threads.
>
> As an aside note I had to throw a kill -9 to Weblogic's JVM in order to
> completely stop it because using the standard "stopWeblogic.sh" script it
> got stalled.
>
> The only unusual thing that I can think of the MDB is doing is opening a
> connection against a remote system via a socket.
>
> My question is. Is it possible that a thread locked on I/O (in this case a
> socket) to be out of control in terms of throwing at it a "Transaction
> rolled back exception"?
>
> I have modified my code in order to set SO_TIMEOUT on the socket just in
> case the other peer hangs and never returns control. But I would like to
> know the problem could be there.
>
> I know for sure that at the time the thread stalled the other peer died
> (exceptions on other MDBs trying to connect to remote system) but I expected
> a "socket exception" to be thrown by the O.S. to the stalled thread instead
> of having the thread waiting forever on that "open" socket.
>
> Thanks in advance.
>
> Ignacio.
>
>
-
Hi,
In my stateless session bean , I am calling a function which
inserts two records in the db. I am failing the second insert ,
so the previous insert should also fail. But its not happening.
I am working on WL6.1. Using datasource.
When in my code, if I say connection.setAutoCommit(false) then
it is showing me the right behaviour even if the db server have
this option disabled already. I am using Oracle thin driver.
What I am doing wrong ?
Thanks
AshwaniOk, Thanks all for your replies
Ashwani
"Raj" <[email protected]> wrote:
>
Yes, instaed of using a DAtaSource in ur config files, create a TxDatasource
and use it.
"Ashwani Kalra" <[email protected]> wrote:
"Emmanuel Proulx" <[email protected]> wrote:
Are you using a TXDataSource?
Emmanuel
"Ashwani Kalra" <[email protected]> wrote in message
news:3d1159ed$[email protected]..
Hi,
In my stateless session bean , I am calling a function which
inserts two records in the db. I am failing the second insert ,
so the previous insert should also fail. But its not happening.
I am working on WL6.1. Using datasource.
When in my code, if I say connection.setAutoCommit(false) then
it is showing me the right behaviour even if the db server have
this option disabled already. I am using Oracle thin driver.
What I am doing wrong ?
Thanks
Ashwani
No, It means if I am using normal datasource then, I have to handle itin
my code.
Cant I set this at configuration time.
Thanks
Ashwani -
Pl Clear my doubts on Stateless session Bean
Is it necessry to Have isolation level and transaction attribute to be mentioned Stateless session Bean.
and where this to be done.
Help is highly appreciatedThere are default (leaving transaction state alone) - so you don't have to specify it.
I'm open to correction: isolation level is specified by the vendor specific configuration whereas transaction attributes are defined in ejb-jar.xml
isolation level is a tuning parameter, whereas the transaction attribute is a design issue.
You shouldn't specify transaction where they don't need. I have seen a number of applications where full transaction level is specified on all methods, and then they wonder why their application is slow.
A transaction is only required if atomic operations are in place. For instance, you don't need transactions on a getter, you may need them though on a setter, iff the setter does more than one thing and those things depend on each other. -
Not be able to obtain a transacted session within stateless session bean
I need some assistance on creating a transacted session. For some reason while within a stateless session bean, I am unable to create a transacted session even though I'm specifying to create the transacted queue session. Can anyone provide any assistance to me on this? It would be much appreciated.
Here is the code snippets involved with the problem:
Code snipet from ejb-jar.xml:
<session>
<display-name>Initial Request</display-name>
<ejb-name>InitialRequestBean</ejb-name>
<ejb-class>com.raytheon.rds.jms.InitialRequestBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
Code from stateless session bean:
static Logger logger;
private QueueConnectionFactory connectionFactory;
private SessionContext sc;
private Queue requestQueue;
public String processRequest(String msgBody)
logger.log(Level.INFO, "In processRequest(String).", msgBody);
QueueConnection con = null;
QueueSession session = null;
QueueSender sender = null;
TextMessage message = null;
String messageID = null;
QueueReceiver receiver = null;
TemporaryQueue replyQueue = null;
boolean transacted = false;
try
//Create the infrastructure (ie. The connection & the session)
logger.log(Level.FINE, "Creating connection");
con = connectionFactory.createQueueConnection();
logger.log(Level.FINE, "Creating session");
session = con.createQueueSession(true, Session.AUTO_ACKNOWLEDGE);
//Note: This line above was changed in all possible permutation and still didn't work such as using Session.SESSION_TRANSACTED
transacted = session.getTransacted();
logger.log(Level.FINE, "Is session transacted? : " + transacted);
//Note: This line above is constantly saying false
//Now first, setup the temporary reply queue and its listener
replyQueue = session.createTemporaryQueue();
logger.log(Level.FINE, "Creating receiver/consumer");
receiver = session.createReceiver(replyQueue);
con.start();
//Now create the requestor that will make the request message and put it on the request queue
logger.log(Level.FINE, "Creating Requestor/Producer");
sender = session.createSender(requestQueue);
//Now create the message and make sure that you put the "JMSReplyTo" property to the temporary response queue we just created
message = session.createTextMessage();
message.setJMSReplyTo(replyQueue);
logger.log(Level.FINE, "Created message: " + message.getJMSMessageID());
//Now add the actual info you want to send
message.setText(msgBody);
//Now send the message
logger.log(Level.INFO, "Sending message: " + message.getText());
sender.send(message);
//Now wait until we get a response
logger.log(Level.FINE, "Waiting for the response message");
Message responseMsg = receiver.receive(20000); //Toggle the "0" to specify timeout in millisectionds
//Process the message
logger.log(Level.FINE, "Processing the response message");
if(null != responseMsg)
logger.log(Level.FINE, "responseMsg is : " + responseMsg.toString());
messageID = processMessage(responseMsg);
logger.log(Level.FINE, "Response is : " + messageID);
//close the connection
logger.log(Level.FINE, "Stopping the connection");
con.stop();
catch (Throwable t)
// JMSException could be thrown
logger.log(Level.SEVERE, "Exception Thrown in sendRequest: ", t);
sc.setRollbackOnly();
finally
//Close the sender
if (sender != null)
try
logger.log(Level.FINE, "Closing the sender");
sender.close();
catch (JMSException e)
logger.log(Level.WARNING, "JMSException Thrown when trying to close the sender to the request queue: ", e);
else
logger.log(Level.FINE, "Sender is already closed.");
//Close the receiver
if (receiver != null)
try
logger.log(Level.FINE, "Closing the receiver");
receiver.close();
catch (JMSException e)
logger.log(Level.WARNING, "JMSException Thrown when trying to close the receiver to the request queue: ", e);
else
logger.log(Level.FINE, "Receiver is already closed.");
//Close the session
if (session != null)
try
logger.log(Level.FINE, "Closing the session");
session.close();
catch (JMSException e)
logger.log(Level.WARNING, "JMSException Thrown when trying to close the session to the request queue: ", e);
else
logger.log(Level.FINE, "Session is already closed.");
//Close the connection
if (con != null)
try
logger.log(Level.FINE, "Closing the connection");
con.close();
catch (JMSException e)
logger.log(Level.WARNING, "JMSException Thrown when trying to close the connection to the reply queue: ", e);
else
logger.log(Level.FINE, "Connection is already closed.");
return messageID;
}I found the answer through lots of painful searching.
http://blogs.sun.com/fkieviet/entry/request_reply_from_an_ejb
This weblog from Frank Kieviet from a sun blog explains what's happening behind the scenes.
Then I proceeded to create a Bean-Managed Transaction out of my EJB, which is using EJB 3.0. This requires the tag:
@TransactionManagement(value= TransactionManagementType.BEAN)
Note: I got this information from http://download.oracle.com/docs/cd/B31017_01/web.1013/b28221/servtran001.htm#BAJIBAFF
Then I just added the code specified in Frank's blog and everything is working now. The main portion of the code looks like this now:
//begin the user transaction
ctx.getUserTransaction().begin();
//Create the infrastructure (ie. The connection & the session)
logger.log(Level.FINE, "Creating connection");
con = connectionFactory.createQueueConnection();
//Create the session
logger.log(Level.FINE, "Creating session");
session = con.createQueueSession(false, Session.SESSION_TRANSACTED);
transacted = session.getTransacted();
logger.log(Level.FINE, "Is session transacted? : " + transacted);
//Now create the sender that will make the request message and put it on the request queue
logger.log(Level.FINE, "Creating Sender");
sender = session.createSender(requestQueue);
//Now create the message
message = session.createTextMessage();
//Now add the actual info you want to send
message.setText(msgBody);
logger.log(Level.FINE, "Created message: " + message.getJMSMessageID());
//Now first, setup the temporary reply queue and its listener
replyQueue = session.createTemporaryQueue();
if(null != replyQueue)
logger.log(Level.FINE, "Created temporary queue: " + replyQueue.getQueueName());
else
logger.log(Level.FINE, "Temporary Queue could not be created.");
//make sure that you put the "JMSReplyTo" property to the temporary response queue we just created
message.setJMSReplyTo(replyQueue);
//Now send the message
logger.log(Level.INFO, "Sending message: " + message.getText());
sender.send(message);
//Now start the connection
logger.log(Level.FINE, "Starting the connection");
con.start();
//commit the changes
ctx.getUserTransaction().commit();
ctx.getUserTransaction().begin();
//Create the receiver
logger.log(Level.FINE, "Creating Receiver");
receiver = session.createReceiver(replyQueue);
//Now wait until we get a response
logger.log(Level.FINE, "Waiting for the response message");
Message responseMsg = receiver.receive(20000); //Toggle the "0" to specify timeout in millisectionds
//Process the message
logger.log(Level.FINE, "Processing the response message");
if(null != responseMsg)
logger.log(Level.FINE, "responseMsg is : " + responseMsg.toString());
else
logger.log(Level.FINE, "No response came back.");
messageID = processMessage(responseMsg);
logger.log(Level.FINE, "Response is : " + messageID);
logger.log(Level.FINE, "Transaction is complete");
//commit the changes
ctx.getUserTransaction().commit(); -
Bean-managed stateless session bean can't roll back using JTA
I use weblogic6.1sp2 + jdk131
a stateless session bean must do 2 things:
insert a record to A table and delete another record in A table
this bean has the same structure as the example in
j2eetutorial/examples/src/ejb/teller
I use TxDataSource in weblogic
if delete fail, the roll back is run,but in database,
the insert record is STILL in A table.
any idea?make sure that your deployment descriptor says "transaction required".
Also, If the insert and delete are two different methods, the client must call these two methods in the same transaction scope. -
EJB Stateless Session Bean Transactions
I have a stateless session bean.
Its deployment descripter references a JDBC DataSource.
It uses container managed transactions.
If I make JDBC calls, within a business method
of this stateless session bean, with the referred datasource, is it attached
to a container managed transaction?If I make JDBC calls, within a business method
of this stateless session bean, with the referred
datasource, is it attached
to a container managed transaction?IIRC, yes. For CMT, the container will roll back any JDBC actions carried out by a method if it fails. -
Transaction management in stateless session beans.
Hi all,
I am using EJB 1.1.
I have a statless session bean that has two methods- A and B.
which does not involve any database interaction
like inserting/updating/deleting the data in the database.
The process flow is such the client always calls A first followed by the call to B.
I have the Transaction attribute set as TX_REQUIRED at the whole bean level.
Now my question is as follows:
Since it is a stateless bean, ejbCreate() is called for every method's invocation.
So does it mean that a new transaction is started for every method invocation?
Also since a transaction ends by commit/rollback.
The transation associated with the method A/B will never get completed as there is no commit/rollback involved in method implementation.
So how is this transaction ended?
Any more details about the transaction management in stateless session beans is highly appreciated.
Any input at the earliest is highly appreciated.
Thanks in advance.Since it is a stateless bean, ejbCreate() is called for every method's invocation.For stateless session bean , Create() is not delegated to the instance.
So does it mean that a new transaction is started for every method invocation?This depends opon the Tx attribute and sequence of calls. Since you have given Tx_required then if you call any method and there is no Tx context associated with client,then a new TX will be started by container othere wise it will execute in the same TX context as the calling client. Note that client can be jsp or other ejb method.
Also since a transaction ends by commit/rollback.
The transation associated with the method A/B will never get completed >as there is no commit/rollback involved in method implementation.
So how is this transaction ended?If you are using COntainer managed TX then Transaction handling like starting , ending etc is handled by the container. You need not worry about that.
Any more details about the transaction management in stateless session >beans is highly appreciated.
Any input at the earliest is highly appreciated.Some time back I had read the article on how the Transaction management done by container on IBM Site. I dont have URL , but you can search the site.
HTH
-Ashwani -
Once Again: Transaction is not rolled back...
Hi all,
I'm almost at the end of my project with Toplink. but I have to solve this transaction rollback problem. Here is my previous message. any comment is more than welcome.
The problem is this, I pass 2 objects to Toplink to update in database using activeUnitOfWork.shallowMergeClone() method.
one of the updates fails then I expect everything to be rolled back within the same unitofwork. but NOT. the other object is quite well updated in database even though they are merged in the same unit of work... please HELP...
here is the log :
UnitOfWork(31228)--JTS#beforeCompletion()
UnitOfWork(31228)--#executeQuery(WriteObjectQuery(com.vnu.publitec.axis.persistence.Parameters@7a0b))
UnitOfWork(31228)--Connection(31249)--UPDATE PARAMETERS SET PARAM_VALUE = '26' WHERE (PARAM_NAME = 'TEST_PARAMETER_2')
UnitOfWork(31228)--#reconnecting to external connection pool
UnitOfWork(31228)--#executeQuery(WriteObjectQuery(com.vnu.publitec.axis.persistence.Parameters@7a06))
UnitOfWork(31228)--Connection(31249)--UPDATE PARAMETERS SET PARAM_MAX_SIZE = 666666, PARAM_COMMENTS = 'updated by new axis...', PARAM_VALUE = '18' WHERE (PARAM_NAME = 'TEST_PARAMETER_1')
UnitOfWork(31228)--EXCEPTION [TOPLINK-4002] (TopLink - 9.0.3 (Build 423)): oracle.toplink.exceptions.DatabaseException
EXCEPTION DESCRIPTION: java.sql.SQLException: ORA-01438: value larger than specified precision allows for this column
INTERNAL EXCEPTION: java.sql.SQLException: ORA-01438: value larger than specified precision allows for this column
...... //some more message
UnitOfWork(31228)--JTS#afterCompletion()
UnitOfWork(31228)--release unit of work
ClientSession(31229)--client released
environment information is :
J2EE Server is Oracle9iAS (9.0.3.0.0) Containers for J2EE
and following is a piece of sessions.xml file related to external transaction controller settings :
<session-type>
<server-session/>
</session-type>
<login>
<datasource>java:comp/env/jdbc/xxx</datasource>
<uses-native-sql>true</uses-native-sql>
<uses-external-transaction-controller>true</uses-external-transaction-controller>
<uses-external-connection-pool>true</uses-external-connection-pool>
</login>
<external-transaction-controller-class>oracle.toplink.jts.oracle9i.Oracle9iJTSExternalTransactionController</external-transaction-controller-class>
thanks
Erdem.Hi James,
As Erdem is not available, I am now taking care of the issue. The datasource name in session.xml refers to the one defined in OC4J data-sources.xml "ejb-location" attribute of "data-source" element. Below, I attach the relevant sections of both files
session.xml
<session>
<name>Axis_session</name>
<project-xml>AxisCDM.xml</project-xml>
<session-type>
<server-session/>
</session-type>
<login>
<datasource>java:comp/env/jdbc/AXIS_323DS</datasource>
<uses-native-sql>true</uses-native-sql>
<uses-external-transaction-controller>true</uses-external-transaction-controller>
<uses-external-connection-pool>true</uses-external-connection-pool>
</login>
<external-transaction-controller-class>oracle.toplink.jts.oracle9i.Oracle9iJTSExternalTransactionController</external-transaction-controller-class>
data-sources.xml:
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="AXIS_323DS"
location="jdbc/AXIS_323CoreDS"
xa-location="jdbc/xa/AXIS_323XADS"
ejb-location="jdbc/AXIS_323DS"
connection-driver="oracle.jdbc.driver.OracleDriver"
username="XXX"
password="XXX"
url="jdbc:oracle:oci8:@ddb"
inactivity-timeout="30"
connection-retry-interval="1"
/>
On the client we get the following exception:
com.evermind.server.rmi.OrionRemoteException: Transaction was rolled back: Error in transaction: EXCEPTION [TOPLINK-4002] (TopLink - 9.0.3 (Build 423)): oracle.toplink.exceptions.DatabaseException
EXCEPTION DESCRIPTION: java.sql.SQLException: ORA-01438: value larger than specified precision allows for this column
On the server, we have implemented SessionSynchronization to monitor the transaction. afterCompletion method gets a boolean value "true" indicating that the transaction was comitted.
Any database operation that was successful before the erroneous case was saved in DB.
Thanks,
Melih -
Transactional error when using JMS from stateless session bean
I get a transaction exception when committing a bean method responsible for sending to a JMS topic. This happens only occasionally when two separate threads invoke this method "at the same time".
The scenario:
Two separate threads running two different instances of a stateless session bean (slsb A). This ejb (slsb A) has an injected slsb B which is communicating with the the topic.
Both instances of slsb A are utilising the same instance of slsb B.
The CMT transactions for the two threads start in slsb A from methods with transaction attribute "RequiresNew". All nested methods are to other slsbs and have the transaction attribute "Required". The method in slsb B which sends the message is closing both the session and the connection to the topic.
I'm running Glassfish version 9.1_02 (build b04-fcs) and JMS implementation OpenMQ version 4.1.
Stacktrace (glassfish log):
[#|2008-09-09T13:00:40.515+0200|SEVERE|sun-appserver9.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=108e8418-71a6-4d8b-a94d-9e1edc885891;|commitTransaction (XA) on JMSService:jmsdirect failed for connectionId:5754505514139844608 and onePhase:false due to unkown JMSService server error.|#]
[#|2008-09-09T13:00:40.515+0200|SEVERE|sun-appserver9.1|javax.enterprise.system.core.transaction|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe;commit;_RequestID=108e8418-71a6-4d8b-a94d-9e1edc885891;|JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation.|#]
[#|2008-09-09T13:00:40.531+0200|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;SubscriptionBean;|EJB5018: An exception was thrown during an ejb invocation on [SubscriptionBean]|#]
[#|2008-09-09T13:00:40.531+0200|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;|
javax.ejb.EJBException: Unable to complete container-managed transaction.; nested exception is: javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:321)
at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3585)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
at $Proxy130.requestNewSubscription(Unknown Source)
at com.abeldrm.kms.core.services.subscription.SubscriptionWSBean.requestNewSubscription(SubscriptionWSBean.java:94)
at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
at $Proxy129.requestNewSubscription(Unknown Source)
at sun.reflect.GeneratedMethodAccessor126.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81)
at com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java:329)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:226)
at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
IMQ broker log:
[09/Sep/2008:13:00:40 CEST] ERROR CommitTransaction: commit failed. Connection ID: 5754505514139844608, Transaction ID: 0:
com.sun.messaging.jmq.jmsserver.util.BrokerException: Unknown Transaction 0
at com.sun.messaging.jmq.jmsserver.data.protocol.ProtocolImpl.commitTransaction(ProtocolImpl.java:630)
at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.commitTransaction(IMQDirectService.java:1735)
at com.sun.messaging.jms.ra.DirectXAResource.commit(DirectXAResource.java:201)
at com.sun.jts.jtsxa.OTSResourceImpl.commit(OTSResourceImpl.java:114)
at com.sun.jts.CosTransactions.RegisteredResources.distributeCommit(RegisteredResources.java:795)
at com.sun.jts.CosTransactions.TopCoordinator.commit(TopCoordinator.java:2111)
at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:403)
at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:249)
at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3585)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
at $Proxy130.requestNewSubscription(Unknown Source)
at com.abeldrm.kms.core.services.subscription.SubscriptionWSBean.requestNewSubscription(SubscriptionWSBean.java:94)
at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
at $Proxy129.requestNewSubscription(Unknown Source)
at sun.reflect.GeneratedMethodAccessor126.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81)
at com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java:329)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:226)
at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Have anyone any idea why this should fail?
Regards,
JonI would suggest opening a case with [email protected] FWIW, I recall seeing
something like this in WLS 6.0. I believe it is fixed in WLS 6.1
-- Rob
Chris Dupuy wrote:
> Btw, this occurs when I create an stateful session bean that ends up
> throwing an exception and setRollbackOnly() is called. From that point
> forward, my logs fill with this message.
>
> Chris
>
> "Chris Dupuy" <[email protected]> wrote in message
> news:[email protected]..
> > anyone know what this means, and what you can do about it?
> >
> >
> > <Error> <ConnectionManager> <atossd03> <cbeyondServer> <ExecuteThread:
> '14'
> > for queue: 'd
> > efault'> <> <> <000000> <Closing:
> 'weblogic.rjvm.t3.T3JVMConnection@488831'
> > because of: 'Server received a message over an uniniti
> > alized connection: 'JVMMessage from: 'null' to:
> >
> '5825313123619479267S:10.6.6.40:[8000,8000,8001,8001,8000,8001,-1]:cbeyond:c
> > beyond
> > Server' cmd: 'CMD_REQUEST', QOS: '101', responseId: '2', invokableId: '1',
> > flags: 'JVMIDs Not Sent, TX Context Not Sent', abbrev o
> > ffset: '204'''>
> >
> >
> >
Maybe you are looking for
-
My grandson was on my computer and messed it up. I am currently running in a text mode with a voice detailing everything I do. How do I get back to normal?
-
Ethernet interface disappears after waking up from sleep
Hi guys, I've been trying to debug a networking problem without any luck and I think it's about time I ask the forum for help. My ethernet interface no longer works after I wake up my computer from sleep. I have no idea why. Before sleep: # ls /sys/c
-
Custom menu buttons adding submenu buttons?
HEEEELLLLLLLLPPPPPPPP I made these custom buttons but is there a way to add a submenu of 7 buttons to one of the buttons so that the other buttons appear below the top custom button on hover? http://www.eurotechengineering.co.uk/
-
Cant start rented film, Error Message (-42110)
Whenever I try to start a film rented from the iTunes Store, there is just the error message "(-42110)". The money is gone, though. What can I do?
-
Hi Guys, I've been using hibernate as the persistence mechanism in an enterprise project for a while now. Originally the datamodel was architected to use a DAO to store (through hibernate) and the BusinessObjects (BO's) would use/update the DO's for