Max number of instances for stateful session beans

Hi,
I am using OC4J 9.0.3 which is embedded in JDeveloper. I would like to set the maximum number of instances for stateful session beans. I know that the session-deployment section of the orion-ejb-jar.xml file has an attribute called max-instances, but it only works for stateless session beans. (at least it says so in the documentation and it did not work with my stateful session bean)
Anyone knows how to do it?
Thanks,
Leonardo Penha

Leonardo -- Stateful session beans do not come from a pool but are assigned 1 bean to 1 user. When the EJBs life ends the bean goes away. If what you are asking about is passivation configuraiton then that is different. We currently do not support passivation based on some count of SFSBs that exists inside the container but we will provide that capability in the next release of OC4J. (Note: When passivation occurs is mostly up to the vendors and it is not required by the J2EE 1.3 specification based on performance metrics. What is required is that when a SFSB is passivated it is done correctly and we do that.)
Thanks -- Jeff

Similar Messages

What's the difference between the LRU and NRU strategy for stateful session bean?

Hi,
Does anybody know the difference between the LRU and NRU strategy for
stateful session bean?
Thanks,
Levi

LRU makes the assumption that the bean that has been used a lot recently is
likely to be used again.
NRU simply removes the beans that have not been used for a stipulated amount
of time.
The algorithm for the LRU is much more complicated than the NRU. I think BEA
recommends LRU for better performance and NRU when you have memory
constraints.
"levi" <[email protected]> wrote in message
news:[email protected]..
Hi,
Does anybody know the difference between the LRU and NRU strategy for
stateful session bean?
Thanks,
Levi

In-memory-replace for stateful session bean

When I add "<replication-type>InMemory</replication-type>" at the
          weblogic-ejb-jar.xml file,
          the client can't call this stateful session bean and happen exception.
          If I delete "<replication-type>InMemory</replication-type>" at the
          weblogic-ejb-jar.xml, the client can call this ejb.
          How does the In-memory-replac set?
          Is there any limitations about using the In-memory-replace?
          The weblogic-ejb-jar.xml and the exception are list.
          The weblogic-ejb-jar.xml:
          <?xml version="1.0"?>
          <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 6.0.0
          EJB//EN' 'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>
          <weblogic-ejb-jar>
          <weblogic-enterprise-bean>
          <ejb-name>test_stateful</ejb-name>
          <stateful-session-descriptor>
          <stateful-session-clustering>
          <home-is-clusterable>True</home-is-clusterable>
          <home-load-algorithm>round-robin</home-load-algorithm>
          <home-call-router-class-name>beanRouter</home-call-router-class-name>
          <replication-type>InMemory</replication-type>
          </stateful-session-clustering>
          </stateful-session-descriptor>
          <jndi-name>test_stateful</jndi-name>
          </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          The exception:
          java.rmi.RemoteException: EJB Exception: ; nested exception is:
          java.lang.ClassCastException:
          weblogic.rmi.internal.BasicRequestDispatcher
          java.lang.ClassCastException: weblogic.rmi.internal.BasicRequestDispatcher
          <<no stack trace available>>


This is a Work as designed in my opinion
with NRU ,the container work with an eager remove algorithm, this as stated need pressure at the cache to push the container to remove the beans from the cache ,hence there will no passivation unless the max-beans-in-cache is reached, hence you can try reducing the max-beans-in-cache and see how the caching behaves , if It does not help ,chnage the Algorithm of caching or open a Service Request for us , we can look at this closely
Regards
Anis

Number of Instances of Stateless Session Bean

For a servlet(not SingleThreadModel) not hosted in a distributed environment(the default),the servlet container must use only one instance per servlet declaration.
All instances of a stateless session bean are equivalent.
In this case, why do the EJB container need to create more than one instances per stateless session bean?
thanks.

Would you like to explain why a servlet declaration
has only one instance?Handling the different client requests as separate threads in the service() method of the servlet is more efficient than using a pool of servlets. That's one of the reasons that the SingleThreadModel (usually implemented using a pool) is now deprecated, along with the fact that that model gives the developer a false sense of security as to multithreading issues...
Once we leave the Web tier to handle remote objects (EJBs) or database connections, we have a different problem, since we are faced with objects that are slow to create and tie up much more resources. In the biz and back-end tiers, using a pool of already existing instances gives actually better performance.

Accessing the same stateful session bean from multiple clients in a clustered environment

I am trying to access the same stateful session bean from multiple
          clients. I also want this bean to have failover support so we want to
          deploy it in a cluster. The following description is how we have tried
          to solve this problem, but it does not seem to be working. Any
          insight would be greatly appreciated!
          I have set up a cluster of three servers. I deployed a stateful
          session bean with in memory replication across the cluster. A client
          obtains a reference to an instance of one of these beans to handle a
          request. Subsequent requests will have to use the same bean and could
          come from various clients. So after using the bean the first client
          stores the handle to the bean (actually the replica aware stub) to be
          used by other clients to be able to obtain the bean. When another
          client retrieves the handle gets the replica aware stub and makes a
          call to the bean the request seems to unpredictably go to any of the
          three servers rather than the primary server hosting that bean. If the
          call goes to the primary server everything seems to work fine the
          session data is available and it gets backed up on the secondary
          server. If it happens to go to the secondary server a bean that has
          the correct session data services the request but gives the error
          <Failed to update the secondary copy of a stateful session bean from
          home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          to the primary server will not reflect changes made on the secondary
          and vice versa. If the request happens to go to the third server that
          is not hosting an instance of that bean then the client receives an
          error that the bean was not available. From my understanding I thought
          the replica aware stub would know which server is the primary host for
          that bean and send the request there.
          Thanks in advance,
          Justin


          If 'allow-concurrent-call' does exactly what you need, then you don't have a problem,
          do you?
          Except of course if you switch ejb containers. Oh well.
          Mike
          "FBenvadi" <[email protected]> wrote:
          >I've got the same problem.
          >I understand from you that concurrent access to a stateful session bean
          >is
          >not allowed but there is a
          >token is weblogic-ejb-jar.xml that is called 'allow-concurrent-call'
          >that
          >does exactly what I need.
          >What you mean 'you'll get a surprise when you go to production' ?
          >I need to understand becouse I can still change the design.
          >Thanks Francesco
          >[email protected]
          >
          >"Mike Reiche" <[email protected]> wrote in message
          >news:[email protected]...
          >>
          >> Get the fix immediately from BEA and test it. It would be a shame to
          >wait
          >until
          >> December only to get a fix - that doesn't work.
          >>
          >> As for stateful session bean use - just remember that concurrent access
          >to
          >a stateful
          >> session bean is not allowed. Things will work fine until you go to
          >production
          >> and encounter some real load - then you will get a surprise.
          >>
          >> Mike
          >>
          >> [email protected] (Justin Meyer) wrote:
          >> >I just heard back from WebLogic Tech Support and they have confirmed
          >> >that this is a bug. Here is their reply:
          >> >
          >> >There is some problem in failover of stateful session beans when its
          >> >run from a java client.However, it is fixed now.
          >> >
          >> >The fix will be in SP2 which will be out by december.
          >> >
          >> >
          >> >Mike,
          >> >Thanks for your reply. I do infact believe we are correctly using
          >a
          >> >stateful session bean however it may have been misleading from my
          >> >description of the problem. We are not accessing the bean
          >> >concurrently from 2 different clients. The second client will only
          >> >come into play if the first client fails. In this case we want to
          >be
          >> >able to reacquire the handle to our stateful session bean and call
          >it
          >> >from the secondary client.
          >> >
          >> >
          >> >Justin
          >> >
          >> >"Mike Reiche" <[email protected]> wrote in message
          >news:<[email protected]>...
          >> >> You should be using an entity bean, not a stateful session bean
          >for
          >> >this application.
          >> >>
          >> >> A stateful session bean is intended to be keep state (stateful)
          >for
          >> >the duration
          >> >> of a client's session (session).
          >> >>
          >> >> It is not meant to be shared by different clients - in fact, if
          >you
          >> >attempt to
          >> >> access the same stateful session bean concurrently - it will throw
          >> >an exception.
          >> >>
          >> >> We did your little trick (storing/retrieving handle) with a stateful
          >> >session bean
          >> >> on WLS 5.1 - and it did work properly - not as you describe. Our
          >sfsb's
          >> >were not
          >> >> replicated as yours are.
          >> >>
          >> >> Mike
          >> >>
          >> >> [email protected] (Justin Meyer) wrote:
          >> >> >I am trying to access the same stateful session bean from multiple
          >> >> >clients. I also want this bean to have failover support so we want
          >> >to
          >> >> >deploy it in a cluster. The following description is how we have
          >tried
          >> >> >to solve this problem, but it does not seem to be working. Any
          >> >> >insight would be greatly appreciated!
          >> >> >
          >> >> >I have set up a cluster of three servers. I deployed a stateful
          >> >> >session bean with in memory replication across the cluster. A client
          >> >> >obtains a reference to an instance of one of these beans to handle
          >> >a
          >> >> >request. Subsequent requests will have to use the same bean and
          >could
          >> >> >come from various clients. So after using the bean the first client
          >> >> >stores the handle to the bean (actually the replica aware stub)
          >to
          >> >be
          >> >> >used by other clients to be able to obtain the bean. When another
          >> >> >client retrieves the handle gets the replica aware stub and makes
          >> >a
          >> >> >call to the bean the request seems to unpredictably go to any of
          >the
          >> >> >three servers rather than the primary server hosting that bean.
          >If
          >> >the
          >> >> >call goes to the primary server everything seems to work fine the
          >> >> >session data is available and it gets backed up on the secondary
          >> >> >server. If it happens to go to the secondary server a bean that
          >has
          >> >> >the correct session data services the request but gives the error
          >> >> ><Failed to update the secondary copy of a stateful session bean
          >from
          >> >> >home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          >> >> >to the primary server will not reflect changes made on the secondary
          >> >> >and vice versa. If the request happens to go to the third server
          >that
          >> >> >is not hosting an instance of that bean then the client receives
          >an
          >> >> >error that the bean was not available. From my understanding I
          >thought
          >> >> >the replica aware stub would know which server is the primary host
          >> >for
          >> >> >that bean and send the request there.
          >> >> >
          >> >> >Thanks in advance,
          >> >> >Justin
          >>
          >
          >

What are the advantages stateful session beans takes over than HttpSession

Hi
We can use HttpSession to maintain the conversational state with the client.
Then why we need to go for stateful session beans to maintain conversational state with the client.
What are advantages we can have while using stateful session beans ratherthan HttpSession????.
Regards
Dhinesh kumar R

I think we can use the magic word in the software development "seperation of concerns" ;-)
HttpSession is in the Servlet/JSP tier and is mainly used in the presentation logic tier (UI, page flows, navigation etc..)
where the stateful session bean's concern is to maintain a conversational state in a business logic tier.
Through this seperation its possible, that the business tier's state is undependant from the HttpSession and you dont create a hardlink that could cause problems later. Imagine having a desktop client accessing your business logic etc. not every client needs to be a web client ;-)
I hope that the answer helps you understanding the topic :-)
Brgds,
Nail

How to get the Stateful Session bean instance in the second call

Hi,
I am new to EJBs. I have made a Stateful session bean on the first jsp page. In this page i am setting certain member variables of the EJB. Now in the second page i want to get these stored values in the EJB.
In the second page do I...
1. Store the instance of Remote Interface in the Session Context of the first JSP page and then in the second page get the Remote interface stored in its session context and call the business functions to get the values. If this is the case then what do u mean by Stateful Session beans??
P.S.- This works fine.
2. Try to get the Remote interface of that particular instance of the EJB(in which the values were stored) and call its business functions. IF this is possible. How do i do it??
thanks in advance
Anurag

Hi,
thanks for information. But i have one question. In a stateful session bean why do we have to store the Remote Interface on the client side.
I expected in the second jsp page when i do a lookup or create, the container/server should find out whether there is a session bean already created for this session if yes, then return that particular instance of the session bean else create a new one.
If this is not a possible case then a stateful session bean is nuthing but an instance of an object in the EJB container which does not get destroyed unless there is a time out or the remove method is called. It has nuthing to do with session because throughout the session I have to store the remote interface in the session context of the client( the client here means the jsp).
thanks in advance
Anurag

SAME EJB 3.0 Stateful Session bean for different JSP sessions returned

Forum,
I have a strange problem utilizing stateful session beans. Please note, that I am using jdeveloper for the following:
1) Here is a basic stateful session bean:
@Stateful(name = "DemoClass")
public class DemoClassBean implements DemoClass,
           DemoClassLocal, SessionSynchronization {
      public static int id=0;
      public DemoClassBean() {
      id++;
      public int getId() {
         return id;
      //... other methods
}2) This bean is accessed from a JSP for testing purpose, I am copying only the script used in JSP:
<%
   DemoClass bean = null;
   try {
      bean = (DemoClass) ((new javax.naming.InitialContext()).
                   lookup("DemoClass "));
      System.out.println("ID=" + bean.getId() );
      } catch (javax.naming.NamingException e) {
         // TODO
%>If this page is addressed by different clients, from different browsers, the same bean is returned.
Here is what I see in the logs:
ID=1
ID=1
ID=1
The same problem is being observed when this session bean is accessed from a JSF Backing bean.
What could be wrong? Is this a bug in oc4j / jdeveloper (version 10.1.3.3.0)?
Edited by: smw000000001 on Nov 17, 2008 10:52 AM

Hi,
The code for stateful is perfectly fine and working in a normal way. The way you are trying to implement the stateful session bean in your application is wrong.
think of binding the stateful session bean with HttpSession object.
So that you will get a unique stateful session bean object.

Stateful session bean destroying instance variables?

I'm trying to use a stateful session bean as some kind of login controller and to maintain the login id and access level across JSPs and HTMLs so that once logged in, all the JSPs can obtain the login name of the current user (String) and his access level (int).
I use the login.jsp to login and it successfully reports logging in with the correct access level retrieved from database. However, if I go to another JSP (testlogin.jsp), these 2 EJB instance variables are always destroyed and set to null and 0 when I access them again.
What am I missing that my stateful session bean is not saving these instance variables? Do I need to put them in some serializable value objects (create a help VO class?)
I suspected that on different JSP, I call the MemberControllerHome.create() method, it creates a new instance or something but if I don't use the create method how do I get a handle to MemberController at all?
MemberControllerBean.java
public class MemberControllerBean implements SessionBean {
     //initialize in ejbCreate.
     private MemberHome memberHome;
     SessionContext context;
     //Member currentLogin;
     //Current Login
     private String loginID;
     private int accessLevel;
     // Constructor
     public MemberControllerBean() {}
...some code in between...
public void login(String id, String password){
          try{
               Member member = null;
               member = memberHome.findByPrimaryKey(id);
               if(member.getMPassword().equals(password)){
                    this.loginID = member.getMID();
                    this.accessLevel = member.getMAccessLevel();
               else{
                    throw new EJBException("Login failed. Invalid member ID and/or password.");
          } catch (FinderException ex) {
               throw new EJBException("Login failed. Invalid member ID and/or password.");
     public void logout(){
          this.loginID = null;
          this.accessLevel = 4;
     public String getLoginID(){
          return this.loginID;
     public int getLoginAccessLevel(){
          return this.accessLevel;
login.jsp
String mID = request.getParameter("mID");
String mPassword = request.getParameter("mPassword");
out.println("20:" + mID + ":" + mPassword);
if(mID != null && mPassword != null){
     out.println("22:" + mID + ":" + mPassword);
     try{
          InitialContext ic = new InitialContext();
          MemberControllerHome home = (MemberControllerHome) ic.lookup("java:comp/env/ejb/MemberController");
          MemberController mc = home.create();
          out.println("26:Logging in as " + mID + " with " + mPassword);
          mc.login(mID, mPassword);
          out.println("28:" + mc.getLoginID() + "logged in successfully at level " +
               mc.getLoginAccessLevel() + ".");
     } catch (NamingException ex) {
          out.println("java:comp/env/ejb/MemberController not found.");
     } catch (EJBException ex) {
          out.println(ex.getMessage());
     } catch (Exception ex) {
          out.println(ex.getMessage());
testlogin.jsp
<%
try{
     InitialContext ic = new InitialContext();
     MemberControllerHome home = (MemberControllerHome) ic.lookup("java:comp/env/ejb/MemberController");
     MemberController mc = home.create();
     out.println("You are logged in as <b>" + mc.getLoginID() +
          "</b> at level <b>" + mc.getLoginAccessLevel() + "</b>.");
} catch (NamingException ex) {
     out.println("java:comp/env/ejb/MemberController not found.");
} catch (EJBException ex) {
     out.println(ex.getMessage());
} catch (Exception ex) {
     out.println(ex.getMessage());
%>

The key to the problem is that in testlogin.jsp a new stateful session bean is created. The new bean instance of course doesn't know the log-in information you stored in the old session bean. That is why the method returns null and 0 when called.
There are couple of ways to solve the issue. The easiest solution is to store the bean instance created in Login.jsp in the jsp's implicit HttpSession object. Because login.jsp and testlogin.jsp share the same session, the bean instance can be easily stored and retrieved.
Here is the code you need to have:
1. in login.jsp
session.setAttribute("MemberControllerBeanInstance", mc);
2. in testlogin.jsp
MemberController mc =
(MemberController) session.getAttribute("MemberControllerBeanInstance");
Hope it helps.

Problem using application client for local stateful session bean

Hi,
I have deployed a local stateful session bean in Sun J2EE 1.4 application server.
On running the applclient for the stateful session bean application client i get the following error:
Warning: ACC006: No application client descriptor defined for: [null]
cant we use application client for local stateful session beans. becoz the application runs smoothly when i changed the stateful sesion bean to remote.

Hi,
No, an ejb that exposes a local view can only be accessed by an ejb or web component packaged within the same application. Parameters and return values for invocations through the ejb local view are passed by reference instead of by value. That can't work for an application client since it's running in a separate JVM.
--ken

EJB 3.0 Stateful session bean shared between Servlet's

Hello
I have a bit of a noob question regarding Stateful sessions beans.
I am wanting to know if there is a way that I can share an instance of a session bean between multiple HttpServlet instances?
I am sending XML messages from a mobile J2ME application, there will be several http POST's made from the mobile client to the server. I would like these multiple POST's to be passed from the handling servlet instance to the same uniquely identified single stateful session bean instance (i can then @Remove the stateful bean when I have finished my several requests).
I would greatly appreciate any tips anyone could give me.

If not, your only option is to maintain the
association yourself by creating a unique id for
each
conversation and storing that id along with the SFSB
reference in the ServletContext. Then you'll
need to pass the id in along with each invocation to
retrieve the appropriate SFSB reference.Thanks for your reply.
Will I always be presented with the same ServletContext instance? Even if the time between requests might be many minutes? Where can I learn more about how to use the ServletContext?
Thanks!

Context.lookup in a Servlet always returns the same Stateful Session Bean

Hi,
I am working on an application in which a Servlet should obtain one StateFul Session Bean per client. I read in EJB 3.0 in Action that to do so I should use a jndi lookup and save the result of the lookup in an HttpSession. This works fine for me when I have a single client.
My issue is that when I have several clients, context.lookup returns the same SFSB for each client. This means that I end up having a single SFSB for the whole application. I've been browsing the web for a while now trying to find a solution but haven't had any luck yet.
The code I use to obtain and save the SFSB is the following:
HttpSession session = request.getSession(true);
DFMServiceRemote service = (DFMServiceRemote) session.getAttribute("DFMService");
if (null == service)
service = (DFMServiceRemote) new InitialContext().lookup("DFMService");
session.setAttribute("DFMService", service);
}Using different browser, I end up with different HttpSession but a single SFSB. The only workaround I found is to create the context with environment variables or properties. It then returns different SFSBs for different HttpSession. The workaround code is as below:
Hashtable<String, String> env = new Hashtable<String, String>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
env.put(Context.SECURITY_PRINCIPAL, "oc4jadmin");
env.put(Context.SECURITY_CREDENTIALS, "welcome");
env.put(Context.PROVIDER_URL, "ormi://localhost:23791/DriverFatigue");
service = (DFMServiceRemote) new InitialContext(env).lookup("DFMService");My question is the following. How can I get a different instance of an SFSB every time I execute context.lookup without specifying properties.
Thanks in advance for any help,
Matthieu Siggen

I just did something similar in another project using JBoss instead of oc4j and didn't have any problem. I expect I missed a configuration file in oc4j or there is a conflict somewhere.

How to track the stateful Session Bean?

Hi all,
Am in a serious trouble. I have a message driven bean which will get initiated when some message gets dumped into the queue. I have got session bean which i use to process message which my message driven bean takes from the queue.
My problem is, lets say there are 3 msgs in the queue. lets say the messages be "aaaa", "aaaa" and "bbbb".
In this case, when i read the first message, i will create an instance of the session bean to process the message "aaaa". When i receive the second message still i create an instance to process the message "aaaa". When i get the 3rd message, i create an instance to process the message "bbbb".
My problem in this is, i want to create only one instance of session bean for the message "aaaa".
So once i create the instance for session bean for particular message, i need to store the object or something of the instance which i created along with the message. Please help me with what i can store with which i can reffer to the session bean again.
Please see the sample code too.
Thanks in advance,
Ashly
if(msg.equals("aaaa"))
First n;
Object obj = ctx.lookup("ejb/First");
FirstHome home = (FirstHome) PortableRemoteObject.narrow(obj, FirstHome.class);
n = home.create(msg);
}

Hi,
thanks for information. But i have one question. In a stateful session bean why do we have to store the Remote Interface on the client side.
I expected in the second jsp page when i do a lookup or create, the container/server should find out whether there is a session bean already created for this session if yes, then return that particular instance of the session bean else create a new one.
If this is not a possible case then a stateful session bean is nuthing but an instance of an object in the EJB container which does not get destroyed unless there is a time out or the remove method is called. It has nuthing to do with session because throughout the session I have to store the remote interface in the session context of the client( the client here means the jsp).
thanks in advance
Anurag

Stateful session Bean in Model not working

I made a sample application very very simple, and the weblogic server cant find the @stateful annotation on the class. is it there another possibility? here i post the error i get:
[Running application MyTest1 on Server Instance IntegratedWebLogicServer...]
[09:48:51 PM] ---- Deployment started. ----
[09:48:51 PM] Target platform is (Weblogic 10.3).
[09:48:52 PM] Retrieving existing application information
[09:48:52 PM] Running dependency analysis...
[09:48:52 PM] Deploying 3 profiles...
[09:48:53 PM] Wrote Web Application Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1/ViewWebApp.war
[09:48:53 PM] Wrote EJB Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1/ModelEJB.jar
[09:48:53 PM] Wrote Enterprise Application Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1
[09:48:53 PM] Deploying Application...
<03-jun-2010 21H48' CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1275594533727' for task '2'. Error is: 'weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..'
weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:454)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
     at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:391)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
     at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:59)
     Truncated. see log file for complete stacktrace
Caused By: java.io.IOException: No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
     at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:219)
     at weblogic.ejb.spi.EjbDescriptorFactory.createReadOnlyDescriptorFromJarFile(EjbDescriptorFactory.java:93)
     at weblogic.ejb.container.deployer.EJBModule.loadEJBDescriptor(EJBModule.java:1210)
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:382)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
     Truncated. see log file for complete stacktrace
>
<03-jun-2010 21H48' CEST> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating deploy task for application 'MyTest1'.>
<03-jun-2010 21H48' CEST> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:454)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
     at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:391)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
     at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:59)
     Truncated. see log file for complete stacktrace
Caused By: java.io.IOException: No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
     at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:219)
     at weblogic.ejb.spi.EjbDescriptorFactory.createReadOnlyDescriptorFromJarFile(EjbDescriptorFactory.java:93)
     at weblogic.ejb.container.deployer.EJBModule.loadEJBDescriptor(EJBModule.java:1210)
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:382)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
     Truncated. see log file for complete stacktrace
>
#### Cannot run application MyTest1 due to error deploying to IntegratedWebLogicServer.
[09:48:54 PM] #### Deployment incomplete. ####
[09:48:54 PM] Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer)
[Application MyTest1 stopped and undeployed from Server Instance IntegratedWebLogicServer]
and the very simple class with a Local and Remote interfaces at Model project in jDeveloper 11g (11.1.1.3)
package test.core;
import java.util.ArrayList;
import java.util.List;
import javax.ejb.Local;
import javax.ejb.Remote;
import javax.ejb.Stateful;
@Stateful(name = "ControlSessionBean", mappedName = "MyTest1-Model-ControlSessionBean")
public class ControlSessionBean implements ControlSessionRemote,
ControlSessionLocal
private String username;
private String password;
public ControlSessionBean()
public List simple()
List <String> s = new ArrayList();
s.add(username);
s.add(password);
return s;
any suggestions why it is not working??
sincerely
Israel S Llorens

not working... i tried to make the stateful session bean Control.. and is still not working the error i get now is this one:
<04-jun-2010 16H29' CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1275661769594' for task '9'. Error is: 'weblogic.application.ModuleException: Could not setup environment'
weblogic.application.ModuleException: Could not setup environment
     at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1499)
     at weblogic.servlet.internal.WebAppModule.activate(WebAppModule.java:442)
     at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:375)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
     at weblogic.application.internal.flow.ModuleStateDriver.activate(ModuleStateDriver.java:95)
     Truncated. see log file for complete stacktrace
Caused By: weblogic.deployment.EnvironmentException: [J2EE:160200]Error resolving ejb-ref 'gecu.view.LoginBean/controlBean' from module 'GeCU_Web_view_root' of application 'GeCU_Web'. The ejb-ref does not have an ejb-link and the JNDI name of the target bean has not been specified. Attempts to automatically link the ejb-ref to its target bean failed because no EJBs in the application were found to implement the 'gecu.model.ControlSession' interface. Please link or map this ejb-ref to its target EJB and ensure the interfaces declared in the ejb-ref are correct.
     at weblogic.deployment.BaseEnvironmentBuilder.autowireEJBRef(BaseEnvironmentBuilder.java:427)
     at weblogic.deployment.EnvironmentBuilder.addEJBReferences(EnvironmentBuilder.java:502)
     at weblogic.servlet.internal.CompEnv.activate(CompEnv.java:157)
     at weblogic.servlet.internal.WebAppServletContext.activate(WebAppServletContext.java:3117)
     at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1497)
     Truncated. see log file for complete stacktrace
>
<04-jun-2010 16H29' CEST> <Error> <Deployer> <BEA-149202> <Encountered an exception while attempting to commit the 9 task for the application 'GeCU_Web'.>
<04-jun-2010 16H29' CEST> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating deploy task for application 'GeCU_Web'.>
<04-jun-2010 16H29' CEST> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: Could not setup environment
     at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1499)
     at weblogic.servlet.internal.WebAppModule.activate(WebAppModule.java:442)
     at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:375)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
     at weblogic.application.internal.flow.ModuleStateDriver.activate(ModuleStateDriver.java:95)
     Truncated. see log file for complete stacktrace
Caused By: weblogic.deployment.EnvironmentException: [J2EE:160200]Error resolving ejb-ref 'gecu.view.LoginBean/controlBean' from module 'GeCU_Web_view_root' of application 'GeCU_Web'. The ejb-ref does not have an ejb-link and the JNDI name of the target bean has not been specified. Attempts to automatically link the ejb-ref to its target bean failed because no EJBs in the application were found to implement the 'gecu.model.ControlSession' interface. Please link or map this ejb-ref to its target EJB and ensure the interfaces declared in the ejb-ref are correct.
     at weblogic.deployment.BaseEnvironmentBuilder.autowireEJBRef(BaseEnvironmentBuilder.java:427)
     at weblogic.deployment.EnvironmentBuilder.addEJBReferences(EnvironmentBuilder.java:502)
     at weblogic.servlet.internal.CompEnv.activate(CompEnv.java:157)
     at weblogic.servlet.internal.WebAppServletContext.activate(WebAppServletContext.java:3117)
     at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1497)
     Truncated. see log file for complete stacktrace
>
[04:29:35 PM] #### Deployment incomplete. ####
[04:29:35 PM] Remote deployment failed

Passivation of Connection Object in Stateful Session Bean

Hi all,
I am developing a Stateful session bean that has a Connection object as its instance variable. And this bean starts transaction that spans across multiple method calls and finally either commit or rollback.
BeanClass
UserTransaction utx;
Connection conn;
ejbCreate()
allocateconnection();
ejbRemove()
closeconnection();
ejbActivate()
allocateconnection();
ejbpassivate()
closeconnection();
StartTransaction()
utx = getusertransaction();
utx.begin();
Method1()
do something with database
Method2()
do something with database
CommitTransaction()
utx.commit();
For example, the typical usage of this bean would be:
bean.StartTransaction();
bean.Method1();
bean.Method2();
bean.CommitTransaction();
Here are my two questions:
1. General Question: In order for a Connection object to join a Transaction, Do I have to create the connection after the transaction has started?
2. If the answer to the above question is yes, then: I understand that when this bean get passivated, the UserTransaction instance object would be passivated. And since the connection object can't not be passivated, I have to recreate the connection object in ejbactivate() method, would newly created connection participate in the same Transaction that was being passivated and now activated?

>
Hi all,
I am developing a Stateful session bean that has a
Connection object as its instance variable. And this
bean starts transaction that spans across multiple
method calls and finally either commit or rollback.
BeanClass
UserTransaction utx;
Connection conn;
ejbCreate()
allocateconnection();
ejbRemove()
closeconnection();
ejbActivate()
allocateconnection();
ejbpassivate()
closeconnection();
StartTransaction()
utx = getusertransaction();
utx.begin();
Method1()
do something with database
Method2()
do something with database
CommitTransaction()
utx.commit();
For example, the typical usage of this bean would be:
bean.StartTransaction();
bean.Method1();
bean.Method2();
bean.CommitTransaction();
Here are my two questions:
1. General Question: In order for a Connection object
to join a Transaction, Do I have to create the
connection after the transaction has started?Strictly NO. In fact, the connection is obtained first and then can a transaction begin.
2. If the answer to the above question is yes, then: I
understand that when this bean get passivated, the
UserTransaction instance object would be passivated.
And since the connection object can't not be
passivated, I have to recreate the connection object
in ejbactivate() method, would newly created
connection participate in the same Transaction that
was being passivated and now activated?
The answer to first question being NO, your argument for question 2 does not hold true. According to the EJB specification, a stateful session bean can only be passivated between the transaction and not within a transaction. Your implementation for the stateful EJB is good to work.

Max number of instances for stateful session beans

Similar Messages

Maybe you are looking for