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.

Similar Messages

Registering EJB/Stateless Session Bean Web Service in Registry

Hi verybody!
I would like to know how I can register a Web Service in a registry. The web service is implemented as a session bean.
The problem is not the actual code to register the service, but how and where can I hook this code into the application so that it is started when the application server is started.
I've read the Sun J2EE tutorial which registered the service in the moment when the context for the servlet for an ordinary web client was created. This is not what I want. I would like to register the service when starting the EJB container, without the need to give it a kick from some external interface.
Any help or ideas will be greatly welcome
Regards
PI

1. But I thought you were using a 'stateful session bean'?
2. For stateless session beans, there is no direct link between a remote reference and an instance of the bean. It is safe to hang on to the remote reference as long as you would like, of course it may go stale if the server dies. You will also find that the create() method does not actually contact the server, so doing it each usage costs very little. So, either way you should be fine.
3. As for memory leaks, make sure that you are closing all statements, result sets, etc. promptly. These are commonly the problem. Also, use hprof or some other profile tool to determine what types of data you are allocating and (with better tools) what types of data you may be holding on to references to.
Chuck

J2EE EJB stateless session bean lifecycle

Hi all,
I've developed a stateless session bean to manage starting/stopping a JCo server.
What should I do in order to achieve these goals:
1. The stateless session bean should be created when the SAP J2EE server is started.
2. The stateless session bean may NEVER 'die'.
Thanks,
Jeroen

hi
good
1-
go through these links, which ll give you the idea how to crea the stateless bean.
http://edocs.bea.com/wle/ejbsamp/stateles.htm
http://www.sitepoint.com/print/implement-first-ejbs
2-
http://home.tiscali.nl/illuminate/scbcd/My%20SCBCDE%20Study%20Notes%20-%204%20Session%20Bean%20Lifecycle.htm
thanks
mrutyun^

EJB: Stateless Session Bean create() Question.

Lets say I have a stateless session bean that fetches data from my database. The point of the bean is to just do large SQL searches and funnel data back to the client. The prolem I have is that I am somehow fighting memory leaks. Despite having checked the code a number of times, the memory usage on my appserver continues to climb no matter what I do. I have theorized that the problem might be in the way Im using ma DataFetchBean (DFB).
When I start the client, he obtains a user session. This is a stateful session bean that he uses for almost all communication with the server. Then I call "getDataFetchBean" in the user session which calls DataFetchBeanHome.create(). Then the client holds onto the returned reference, using it for the live of his connection. As he disconnects, he calls remove on the bean.
Question is this:
1) Is it better for me to call create() prior to each call to the stateless session bean ?
2) Do you have any theories on why im loosing memory with this setup?
TIA
-- Rob

1. But I thought you were using a 'stateful session bean'?
2. For stateless session beans, there is no direct link between a remote reference and an instance of the bean. It is safe to hang on to the remote reference as long as you would like, of course it may go stale if the server dies. You will also find that the create() method does not actually contact the server, so doing it each usage costs very little. So, either way you should be fine.
3. As for memory leaks, make sure that you are closing all statements, result sets, etc. promptly. These are commonly the problem. Also, use hprof or some other profile tool to determine what types of data you are allocating and (with better tools) what types of data you may be holding on to references to.
Chuck

EJB Stateless Session Bean how to recompile with "-deprecation" 10.1.2.0.2

I have a EJB SLSB and I can deploy it to OC4J 10.1.2.0.2. However upon deployment OC4J is telling me:
Note: Some input files use or override a deprecated API.
Note: Recompile with -deprecation for detailsCan somebody tell me how I can make OC4J recompile EJBs with -deprecation set to true?

I suppose you'd be the first to start screaming at
them for all the bugs in the 10.1.3 production
release, if the Oracle guys concentrated more on
getting something out quickly rather than providing a
reliable product.C'mon, the only reason I'm pushing this is the fact that from the (OTN) website it looks like 10.1.3 has been around for years, whereas the truth is that the actual production date is unknown. What I am experiencing around me is Oracle loosing credibility regarding Java/J2EE with their direct competitors already having J2EE 1.4 support. The project I'm currently involved in was forced to use 10.1.2.0.2 since it is the last production release of the Oracle Application Server. This is J2EE 1.3 technology which is fairly old stuff.
And... yes I'm amongst other things a developer and well aware of the challenges that come with creating software. Although in our projects we like to keep a relatively clear scope and not cramp as much features as possible in a version, just to satisfy the checklists :-)

How to integrate hibernate with Stateless Session bean in weblogic10.0

Hi,
I need to invoke hibernate(3.x) DAO from EJB Stateless Session bean(EJB2.x). I am using mysql database. Can somebody please post the configuration.
Thanks in advance,
Rushi.

Hi Deepak,
Thanks for your reply.
Actually, our stand alone java application already using spring-hibernate feature. Now we are planning divide our application into modules and deploy each module as ejb beans. As it is already integrated with spring-hibernate we are not using entity beans as of now. My understanding is container uses some default transcation management .so, my question is what are all the configurations needs to be done to let weblogic 10.0 server uses org.springframework.orm.hibernate3.HibernateTransactionManager. I mean, is there are any .xml file in weblogic to configure all these? please reply deepak I am struck here..
Regards,
Rushi.

Calling Stateless Session bean from Servlet

Dear Friends,
A help will be Appreciated...
I created a EJB (Stateless Session Bean) using WebSphere Application Developer with its Business logic in Main bean. Its working perfectly fine using UTC (Standalone Test Client). But when i use a servlet to communicate with this EJB, its giving me error as follows:
Error Stack:
java.lang.NoClassDefFoundError: package name/DemoHome
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:254)
at java.beans.Beans.instantiate(Beans.java:213)
at java.beans.Beans.instantiate(Beans.java:57)
at com.ibm.servlet.engine.webapp.WebAppServletManager.loadServlet(WebAppServletManager.java:148)
at com.ibm.servlet.engine.webapp.WebAppServletManager.getServletReference(WebAppServletManager.java:287)
at com.ibm.servlet.engine.webapp.WebApp.getServletReference(WebApp.java:354)
at com.ibm.servlet.engine.webapp.WebAppRequestDispatcherInfo.calculateInfo(WebAppRequestDispatcherInfo.java:167)
at com.ibm.servlet.engine.webapp.WebAppRequestDispatcherInfo.<init>(WebAppRequestDispatcherInfo.java:51)
at com.ibm.servlet.engine.webapp.WebApp.getRequestDispatcher(WebApp.java:1145)
at com.ibm.servlet.engine.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:179)
at com.ibm.servlet.engine.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:67)
at com.ibm.servlet.engine.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:122)
at com.ibm.servlet.engine.oselistener.OSEListenerDispatcher.service(OSEListener.java:315)
at com.ibm.servlet.engine.http11.HttpConnection.handleRequest(HttpConnection.java:60)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:323)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:252)
at com.ibm.ws.util.CachedThread.run(ThreadPool.java:122)
For more Info let me provide the snipets of how i used the Sevlet:
Client.java
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import packagename.*; //package name of imported ear file which is in
//classpath
public class Client extends HttpServlet {
public void doGet(
javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response)
throws javax.servlet.ServletException, java.io.IOException {
PrintWriter out=response.getWriter();
Properties p = new Properties();
p.put(javax.naming.Context.PROVIDER_URL, "iiop:///");
p.put(javax.naming.Context.INITIAL_CONTEXT_FACTORY,"com.ibm.websphere.naming.WsnInitialContextFactory");
try {
InitialContext initial = new InitialContext(p);
Object objref = initial.lookup("JDemo");
DemoHome home = (DemoHome)PortableRemoteObject.narrow(objref,DemoHome.class);
Demo demo = home.create();
int r=demo.testBean(4);
out.println("EJB RESULT= "+r);
} catch (Exception ex) {
System.err.println("Caught an unexpected exception!");
ex.printStackTrace();
Kindly provide ur solution to this problem. Urgent solution will be helpful as its a part of our present project.
Thanking you for ur esteemed help.
regards,
Arun.

Perhaps you webserver can't see your package jar file.
Try putting it in WEB-INF\lib directory of your app and restart your server.

Some methods not working in EJB 3.0 stateless session bean

Hi,
I am trying to build an application with EJB 3.0 stateless session bean in weblogic 10. In that during build (using ant 1.6) it showing error as one of the ejb-class should have anotataion as @stateless, @stateful or @messageDiven
But i have given it corrrectly.
When I comment some of the methods the same bean is working fine. While i have annoatated some of the methods with @transaction attribute annotataion.
So, should i write all those methods there any particular order or what.
Can anybody pls tell me, what can be the problem as weblogic.appc is giving such error?

Hi,
I am trying to build an application with EJB 3.0 stateless session bean in weblogic 10. In that during build (using ant 1.6) it showing error as one of the ejb-class should have anotataion as @stateless, @stateful or @messageDiven
But i have given it corrrectly.
When I comment some of the methods the same bean is working fine. While i have annoatated some of the methods with @transaction attribute annotataion.
So, should i write all those methods there any particular order or what.
Can anybody pls tell me, what can be the problem as weblogic.appc is giving such error?

Stateless Session Bean + EJB Question + Jboss

Hello,
If I have a stateless session bean on a linux machine and it works locally what do i need to do to access a method in the session bean from a remote windows machine.
I would like to be able to execute my client jar file on a windows machine and have it access the jboss server on the linux machine. what do i need to do?
i have the session bean working locally on both windows and linux machine. do i need to to have a JSP/Servlet to access the session bean? can the session bean not be accessed directly? what should my classpath look like? do I need to include extra jar files in my client jar file.?
Thanks,
Joyce

Thanks guys for the help but I am still a little lost.
My Client windows machine has the client jar file and all the other jar files. This is my client class
package helloworld.client;
import javax.naming.Context;
import javax.naming.InitialContext;
import java.util.Hashtable;
import java.util.Properties;
import helloworld.interfaces.HelloWorldHome;
import helloworld.interfaces.HelloWorld;
public class HelloClient
     public static void main(String[] args)
          Hashtable prop = new Hashtable();
          prop.put ("java.naming.factory.url.pkgs","org.jboss.naming:org.jnp.interfaces");
          prop.put ("java.naming.provider.url","jnp://172.16.220.160:1099");
          prop.put ("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");
          try
               Context ctx = new InitialContext(prop);
               Object obj = ctx.lookup("ejb/helloworld/HelloWorld");
               System.out.println(obj);
               HelloWorldHome home = (HelloWorldHome)javax.rmi.PortableRemoteObject.narrow(obj, HelloWorldHome.class);
               HelloWorld helloWorld = home.create();
               String str = helloWorld.sayHelloEJB("JOYCE is COOL");
               System.out.println(str);
               helloWorld.remove();
          catch(Exception e)
               e.printStackTrace();
I get a NullPointer ie the home object is null. The IP address is the IP of the Linux machine that has Jboss running on.
Questions are:
1. Do I need to have Tomcat running on my client machine if I am to connect via HTTP? Does this alter my client code.?
2. My JNDI lookup is what is causing the problem. Does my jboss.xml and my ejb-jar.jar look okay to you.
jboss.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS//EN" "http://www.jboss.org/j2ee/dtd/jboss.dtd">
<jboss>
<enterprise-beans>
<session>
<ejb-name>helloworld/HelloWorld</ejb-name>
<jndi-name>ejb/helloworld/HelloWorld</jndi-name>
</session>
</enterprise-beans>
<resource-managers>
</resource-managers>
</jboss>
ejb-jar.jar
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar >
<description>No Description.</description>
<display-name>Generated by XDoclet</display-name>
<enterprise-beans>

<session >
<description><![CDATA[No Description.]]></description>
<ejb-name>helloworld/HelloWorld</ejb-name>
<home>helloworld.interfaces.HelloWorldHome</home>
<remote>helloworld.interfaces.HelloWorld</remote>
<ejb-class>helloworld.session.HelloWorldBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Bean</transaction-type>
</session>





</enterprise-beans>


<assembly-descriptor >



</assembly-descriptor>
</ejb-jar>
Do I need RMI ? Do I need to concern myself with CORBA? All Im looking for is a step by step to understanding what I need to configure? Is their some way I can debug?
Thanks alot,
Joyce

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();

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

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

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,
Jon

I 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'''>
          > >
          > >
          > >

Calling EJB 3.0 Stateless Session Bean

Dear all,
I created a stateless session bean with a hello world method on it. Now i want to call the method from a BeanDecorator class, through a getter metod. When i use the jndi lookup in my getter, i can call the helloWorld method without a problem. However, when i dont use the jndi lookup, and only use the @EJB annotation, i always get a nullpointer.
This is working:
InitialContext ic = new InitialContext();
test = (TestLocal)ic.lookup("test.be/ear~bd/LOCAL/TestBean/"+TestLocal.class.getName());
test.helloWorld()
This gives nullpointer:
@EJB
private TestLocal test;
test.helloWorld();
What is the correct way to consume session beans without having to explicitly code the jndi lookup?
Kind regards.

Hi,
any annotation like this can be used only in "managed classes" like Session Beans, Servlets etc. Managed classes are those classes managed by the J2EE server. Managed here means, lifetime controlled by server.
You can find this in J2EE specification.
Frank

How to use jta in toplink and stateless session bean EJB 3.0?

I have an application with techologies jsf,stateless session bean, adf, toplink
generated by toplink workbench.
In web side ı want to use two methods in stateless session bean which are updated
different tables. I call these methods in my page backing bean.
I also want to JTA in web side. My first methods is done correctly, but second method has an error. I wanto to rollback all transaction.
How can ı do that? with using JTA in Toplink...

Yuichi
Did you manage to solve this? I'm doing something similar and seeing the same problem, although they're up to 7.3 SP7.
Any help greatly appreciated.
Lewis

EJB Stateless Session Bean Transactions

Similar Messages

Maybe you are looking for