Help!!! Stateful session bean clustering

          I posted this message on interest.clustering.in-memory-replication. But there is
          no answer at all. Could anyone give me
          some hints? Thanks a lot. I am a student and this work is part of my course project.
          It is due soon.
          =================================================================
          I have a big problem to get stateful session bean in-memory replication run on
          clustering. I have three server instances on three nodes and there is always errors
          from the server instance like this when I run the client to invoke the bean methods:
          <Jan 4, 2002 6:47:31 PM EST> <Error> <EJB> <Failed to update the secondary copy
          of a stateful session bean from home:stateful.ejb.AgentSTF>
          Besides, the load balancing can not work probably too. Below is what I get.
          Statistics for different servers:
          "myserver" processed 160 (12%) of 1311 invocations "ejbperf-3" processed 1151
          (88%) of 1311 invocations
          End Client...
          Load balancing works fine with stateless and entity bean.
          Any comments are greatly appreciated.
          Jenny

Hi Jenny,
          Please could you open a case to the customer support ([email protected]) There is a Cr
          on this issue CR059046
          Description of the CR
          WLS 6.1SP1 - Accessing Stateful Session Bean from Stateless Session Bean in a
          cluster fails with errors
          <Oct 5, 2001 5:08:25 PM GMT+00:00> <Error> <EJB> <Failed to update the
          secondary copy of a stateful session bean from home:UserState>
          Regards
          Stephane
          Jenny Liu wrote:
          > I posted this message on interest.clustering.in-memory-replication. But there is
          > no answer at all. Could anyone give me
          > some hints? Thanks a lot. I am a student and this work is part of my course project.
          > It is due soon.
          >
          > =================================================================
          >
          > I have a big problem to get stateful session bean in-memory replication run on
          > clustering. I have three server instances on three nodes and there is always errors
          > from the server instance like this when I run the client to invoke the bean methods:
          >
          > <Jan 4, 2002 6:47:31 PM EST> <Error> <EJB> <Failed to update the secondary copy
          > of a stateful session bean from home:stateful.ejb.AgentSTF>
          >
          > Besides, the load balancing can not work probably too. Below is what I get.
          >
          > Statistics for different servers:
          > "myserver" processed 160 (12%) of 1311 invocations "ejbperf-3" processed 1151
          > (88%) of 1311 invocations
          > End Client...
          >
          > Load balancing works fine with stateless and entity bean.
          >
          > Any comments are greatly appreciated.
          >
          > Jenny
          >
          Regards,
          Stephane Kergozien
          BEA Support

Similar Messages

Plz help!! idempotent methods stateful session beans? (failover)

          plz help!! idempotent methods stateful session beans? (failover)
          Hi there,
          Im trying to failover my shopping cart implemented using stateful ejb, the replication
          is working but the failover is not (Object not found exception....).
          By design is hard to think on an stateful ejb using idempotent methods, but after
          checking the documentation in detail im completely confused, so im starting to
          wonder if i should use idempotent methods or manual retry in case one server is
          down.
          Plz take a loo at these explanations about faiolver in the WLS edocs.
          "....With clustered objects, automatic failover generally occurs only in cases
          where the object is idempotent.....Because of this, replica-aware stubs will not,
          by default, attempt to retry a method that fails after the request is sent but
          before it returns. This behavior can be overridden by marking a service idempotent..."
          BUT
          "By default, a stateful session bean's Home stub provides load balancing and failover
          for its method invocations to any clustered server where the bean is deployed...."
          So is possible to achieve automatic failover (not only load balancing) for stateful
          ejb without having to worry about state-changes or manual retry. (i know the retry
          is requiered if the server crashed just before finishing a transaction but this
          is not what im talking about).
          Any help will be highly appreciated
          Alan


          Ryan,
          Yes, im deploying using In-memory replication and clusterable elements, when try
          to invoke the method (after one of the nodes is down) i recieve an "java.rmi.NoSuchObjectException:
          Bean has been deleted".
          I believe all this could be related to some sort of issue with JNDI Lookup in
          the cluster, but haavent been able to get a clue to make it work....(almost desesperate
          by now)
          Alan
          "ryan upton" <[email protected]> wrote:
          >Alan,
          >
          >If the state isn't maintained during failover I would suspect a
          >configuration error. Have you set the <replication-type> element within
          ><stateful-session-clustering> tag in the bean's deployment descriptor?
          >
          >"Alan" <[email protected]> wrote in message
          >news:40e17cf7$1@mktnews1...
          >>
          >> Ryan,
          >>
          >>
          >> Maybe i didnt explain myself, in the scenario im dealing with I KNOW
          >the
          >method
          >> finished succesfully (example, the user succesfully added an item to
          >a
          >cart).
          >>
          >>
          >> Just after that one of the nodes goes down, and the user decides to
          >add a
          >new
          >> item (new invocation , not a retry of failed one) on the same session.
          >>
          >> This is the case in which failover should work automatically as you
          >say,
          >meaning
          >> the new method invokation should be able to retrieve the session state
          >info from
          >> the replica and switch the primary.....Well, this is the part wich
          >isnt
          >working
          >> :( as i understand it should transparently
          >>
          >> I believe could be a config issue , but have no way to make it work.
          >>
          >> Regards,
          >>
          >> Alan
          >> "ryan upton" <[email protected]> wrote:
          >> >
          >> >"Alan" <[email protected]> wrote in message
          >news:40e06296@mktnews1...
          >> >>
          >> >> Ryan,
          >> >>
          >> >> Thanks for clearing the both conditions a bit more, in this case
          >my
          >> >issue
          >> >has
          >> >> to do with the scenario #1 in which subsequent calls (invocations)
          >> >go to a
          >> >node
          >> >> which isnt avaliable(down), do you have any idea of in what conditions
          >> >the
          >> >"automnatic"
          >> >> failover would fail??? (meaning why the stub would try to dispatch
          >> >a call
          >> >to the
          >> >> same previous node)
          >> >>
          >> >> Thanks for the help again
          >> >>
          >> >
          >> >Subsequent calls won't go to a node that's down. That's the whole
          >> >point
          >> >;-). Failover is always automatic, what you are getting confused
          >on
          >> >is
          >> >automatic method re-execution upon failover which happens if the method
          >> >has
          >> >been marked as idempotent. The logic is this: if I failover to an
          >EJB
          >> >that
          >> >I know is still alive, I can't safely call the same method again.
          > Why?
          >> >Because I don't know how much of the method completed the last time
          >before
          >> >the previous bean's failure. So if the bean can yield multiple results
          >> >from
          >> >multiple invocations I had better play it safe and not re-execute
          >the
          >> >method
          >> >on the bean I failed over to (unless it's idempotent because in that
          >> >case it
          >> >doesn't matter how many times I call it, it always does the same thing).
          >> > In
          >> >scenario #1 and #2 failover is automatic and all new calls are executed
          >> >against the bean the client failed over to, but only idempotent methods
          >> >are
          >> >re-executed.
          >> >
          >> >
          >>
          >
          >

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

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

HttpSession vs. Stateful Session Bean ---- when State Session is large

I hope most of the people come across with this issue where to put the state
for the internet/intranet based applications when they are using
servlet/jsps calling session beans. Weblogic 4.5.1 does support httpsession
in-memory replication for the servlets but the stateful session beans are
not replicated in clustered environment. Plus with stateful bean u get
activation/passivation overhead too. So one tempts to use stateless session
beans and store state in httpsession?
Then what is the upper limit for the session state one can put in
HttpSession with the weblogic? Is there any way to configure it?
One way to overcome the httpsession size limitation is to use database for
storing state and just store some unique Ids for the session info in
httpSession. But then there will be overhead for database connection?(jdbc
connection pool can provide some help here). So what is the recommended way
for doing this provided few thousand concurrent clients with session size
say exceeding 4kb per client?
Thanks
Usmani

There are no special setting in sun-ejb-jar.xml regarding cache settings. The default settings from server.xml are used:
    <jdbc-connection-pool steady-pool-size="8" max-pool-size="32" max-wait-time-in-millis="60000" pool-resize-quantity="2" idle-timeout-in-seconds="300" is-isolation-level-guaranteed="false" is-connection-validation-required="false" connection-validation-method="auto-commit" fail-all-connections="false" datasource-classname="oracle.jdbc.pool.OracleDataSource" name="ebs">
      <property value="jdbc:oracle:thin:@myebsdbsserver:1521:ebsdevdb" name="url"/>
      <property value="ebs" name="user"/>
      <property value="ebs" name="password"/>
    </jdbc-connection-pool>
<ejb-container steady-pool-size="32" pool-resize-quantity="16" max-pool-size="64" cache-resize-quantity="32" max-cache-size="512" pool-idle-timeout-in-seconds="600" cache-idle-timeout-in-seconds="600" removal-timeout-in-seconds="5400" victim-selection-policy="nru" commit-option="B" monitoring-enabled="true">
     </ejb-container>The Session Bean uses Container Managed Transaction. Is it possible in this case, that the bean isn't 'idle enough' in order to set into passivated?

How create EJB 2.1 Stateful Session Bean in a EJB 3.0 Session Bean

Hi All,
We have been developing on EJB 2.1. We are now adding a module on EJB 3.0.
How can we "create" a stateful session bean with create method signature similar to create(String id)?
We have tried
// this is the remote interface
@EJB AddressBean abean;
But not working
Any help will be appreciated.

There is no explicit create() call for EJB 3.0 session beans. It doesn't really matter though
since you can accomplish the same thing by defining your own business method to act
as an initializer for whatever state you'd like. E.g.
@Remote
public interface FooInterface {
public void initialize(String id);
// ... other business methods
@EJB FooInterface fooRef;
fooRef.initialize("foo");
--ken

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.

Stateful Session Beans are not passivated / serialized when cache idle time

Technology: Sun Application Server version 7.0.0_01; JDK 1.4.1; developed on Windows 2000; Tested on Sun Solaris.
Initial error on Sun Solaris:
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: Exception in thread "service-j2ee-25" org.omg.CORBA.OBJ_ADAPTER: vmcid: SUN minor code: 1015 completed: No
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.GenericPOAServerSC.preinvoke(GenericPOAServerSC.java:389)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.initServant(ServantCachePOAClientSC.java:112)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.setOrb(ServantCachePOAClientSC.java:95)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.createDelegate(CDRInputStream_1_0.java:760)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.internalIORToObject(CDRInputStream_1_0.java:750)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_Object(CDRInputStream_1_0.java:669)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:890)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:884)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream.read_abstract_interface(CDRInputStream.java:307)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:228)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:381)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at java.io.ObjectInputStream.readObject(ObjectInputStream.java:318)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.enterprise.iiop.IIOPHandleDelegate.getStub(IIOPHandleDelegate.java:58)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.enterprise.iiop.IIOPHandleDelegate.readEJBObject(IIOPHandleDelegate.java:38)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.ejb.portable.HandleImpl.readObject(HandleImpl.java:91)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObject(Native Method)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1298)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.inputObject(IIOPInputStream.java:908)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:261)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:247)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:209)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:981)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream.read_value(CDRInputStream.java:287)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.javax.rmi.CORBA.Util.copyObject(Util.java:598)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.rmi.CORBA.Util.copyObject(Util.java:314)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.ejb._NodeMaint_Stub.getHandle(Unknown Source)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.arch.NMAViewBeanProxy.checkBeans(NMAViewBeanProxy.java:631)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.view.html.NMAStandardButton.handleRequest(NMAStandardButton.java:143)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.arch.NMAViewBeanBase.handleRequest(NMAViewBeanBase.java:1573)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.dispatchInvocation(ViewBeanBase.java:824)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandlerInternal(ViewBeanBase.java:637)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandler(ViewBeanBase.java:595)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.dispatchRequest(ApplicationServletBase.java:772)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.processRequest(ApplicationServletBase.java:446)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.doPost(ApplicationServletBase.java:324)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.view.ViewServlet.doPost(ViewServlet.java:243)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.access$000(StandardWrapperValve.java:118)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve$1.run(StandardWrapperValve.java:278)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at java.security.AccessController.doPrivileged(Native Method)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:274)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:158)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
The above error caused the server to use all available memory and required a reboot to proceed.
Subsequent testing against the Sun Appliucation Server 7 on Windows 2000 dev environment using the Sun Studio IDE for debugging and trace statements inserted in the code indicate that the Application Server is removing the Stateful Session Beans when they time out without an ejbPassivate event and without serializing the beans to the data-store. cache-idle-timeout-in-seconds set to 180 and removal-timeout-in-seconds set to 1800.
The server.log indicates that the beans are timing out:
[19/Aug/2004:18:15:10] WARNING ( 1664): [NRU-com.telstra.nodeman.ejb.AddressMaintBean]: IdleBeanCleanerTask finished after removing 2 idle beans
Trace statements inserted in ejbPassivate do not appear in the log.
It is my understanding that the above timeout should have caused an ejbPasssivate and serialization of the beans.
The beans have been validated using Sun Java Studio Enterprise 6 with 'EJB validate'.
My reading of the problem is that the beans are not being serialized and the error occurs when the application attempts to reference (getHandle) the bean after timeout.
Any suggestions would be appreciated.

Thanks Thorick.
I am using NRU caching. WL 7.0 SP2.
I have not defined idle-timeout-seconds in my weblogic-ejb-jar.xml. As I understand
the default value for this is 600secs. So the ejbs should be removed after this
time. Below is the
weblogic-ejb-jar.xml that I am using.
<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN'
'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>

<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>Cart</ejb-name>
<stateful-session-descriptor>
<stateful-session-clustering>
<home-is-clusterable>true</home-is-clusterable>
<replication-type>InMemory</replication-type>
</stateful-session-clustering>
</stateful-session-descriptor>
<transaction-descriptor>
     <trans-timeout-seconds>
          60
     </trans-timeout-seconds>
</transaction-descriptor>
<jndi-name>CartHome</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
"thorick" <[email protected]> wrote:
>
The idle-timeout-seconds property controls the timeout/removal behavior.
which stateful session cache type are you using ? LRUCache or NRUCache

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

Reentrant call to a stateful session bean

Hi,
I have a problem that seems to be a very common problem but I
steel didn't find any solution for it.
We have a jsp page that call to stateful session been, the
problem occur when I click twice on any link/button then I get
java.rmi.RemoteException: Illegal attempt to make a reentrant call to a stateful
session bean from home:....
I have tried to set the <allow-concurrent-calls> to true but it doesn't help,
I am getting this exception no matter the value of this tag.
I am using WL61 sp2 (the last version) , Does anybody find a solution for that,
I don't want to use javascript in order to work around this problem.
Thanks,

I think this is a different error from concurrent access (when client's
attempt to access the same bean concurrently WebLogic throws LockTimedOut error
(or client blocks if allow-concurrent-calls is true)).
This error probably means that your code attempetd to reenter bean in the same
transaction - how do you invoke it and what is the stack trace?
Haim Cohen <[email protected]> wrote:
Hi,
I have a problem that seems to be a very common problem but I
steel didn't find any solution for it.
We have a jsp page that call to stateful session been, the
problem occur when I click twice on any link/button then I get
java.rmi.RemoteException: Illegal attempt to make a reentrant call to a stateful
session bean from home:....
I have tried to set the <allow-concurrent-calls> to true but it doesn't help,
I am getting this exception no matter the value of this tag.
I am using WL61 sp2 (the last version) , Does anybody find a solution for that,
I don't want to use javascript in order to work around this problem.
Thanks, --
Dimitri

Lock Timed out exception in stateful Session Bean

Hi All,
We have a stateful session bean and put the reference of the bean in HttpSession
and retrieve it from other JSP.
While calling a method from bean, we are often getting the following exception.
Any help please?
weblogic.ejb.extensions.LockTimedOutException: Lock for primaryKey:1018581328443_46
could not be acquired without waiting.
at weblogic.ejb.internal.LockManagerImpl.lock(LockManagerImpl.java:134)
at weblogic.ejb.internal.LockManagerImpl.lock(LockManagerImpl.java:81)
at weblogic.ejb.internal.StatefulEJBCache.bind(StatefulEJBCache.java:447)
at weblogic.ejb.internal.StatefulEJBObject.getContextForInvoke(StatefulEJBObject.java:159)
at weblogic.ejb.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:487)
at com.elink.jbe.savejobses.SaveJobSesBeanEOImpl.getJobHeaderData(SaveJobSesBeanEOImpl.java:1258)
at jsp_servlet._jobentry._jbeenquirydefaults._jspService(_jbeenquirydefaults.java:243)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:123)
at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:761)
at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:708)
at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:252)
at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:346)
at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:246)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:135)

Hi Arjuna,
Thanks for your suggestions. But can you also help me how to make the session
bean thread safe?
Thanks in Advance
Srinath
"Arjuna Chala" <[email protected]> wrote:
Looks like you have two threads accessing the bean at the same time.
You
need to make it thread safe. Also, store the handle of the session bean
instead of the session bean itself in the session.
By the way, session beans (handle or otherwise) are not meant to be stored
in the HttpSession, and here is why:
http://groups.google.com/groups?q=stateful+session+bean+httpsession&hl=en&se
lm=3b72acb9%40newsgroups.bea.com&rnum=6
"srinath" <[email protected]> wrote in message
news:[email protected]...
Hi All,
We have a stateful session bean and put the reference of the bean inHttpSession
and retrieve it from other JSP.
While calling a method from bean, we are often getting the followingexception.
Any help please?
weblogic.ejb.extensions.LockTimedOutException: Lock forprimaryKey:1018581328443_46
could not be acquired without waiting.
atweblogic.ejb.internal.LockManagerImpl.lock(LockManagerImpl.java:134)
atweblogic.ejb.internal.LockManagerImpl.lock(LockManagerImpl.java:81)
atweblogic.ejb.internal.StatefulEJBCache.bind(StatefulEJBCache.java:447)
atweblogic.ejb.internal.StatefulEJBObject.getContextForInvoke(StatefulEJBObjec
t.java:159)
atweblogic.ejb.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:487)
atcom.elink.jbe.savejobses.SaveJobSesBeanEOImpl.getJobHeaderData(SaveJobSesBea
nEOImpl.java:1258)
atjsp_servlet._jobentry._jbeenquirydefaults._jspService(_jbeenquirydefaults.ja
va:243)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
atweblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:123)
atweblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
l.java:761)
atweblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
l.java:708)
atweblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContext
Manager.java:252)
atweblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:346)
atweblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:246)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:135)

Handling Transaction in Stateful Session Bean

I wrote a public method like public void doTransaction()
it will call 2 private method, like: methodA and methodB
Both private methods have db accesss statement and will update the db. They got different db connection and will close the connection when method call finished.
How to include them to one transaction? I want to be able to rollback the job of the first method when I catch exception thrown by the second method.
I tried simply define transaction type of the public method to be Container and Required. But it doesn't work, the first method doesn't rollback. Of course I can let the 2 private methods share a same connection and commit after finishing calling them. But how if they are in different DB?

Ok... Here it goes...
You can do it in the following manner.
As you said you have got 2 private methods doing d/b updates and these are called from a public method.
Stateful session beans since associated with a client across methods, you can take advantage of it. Write your own user defined transaction.
Begin the transaction scope in your public before calling the 1st private method. Call the 2 methods in a try block. Once you are done with these methods, you can commit and end the transaction. If you get any exception, rollback the transaction in the catch block. Otherwise if u get any exception in the 2nd method, you can rollback the transaction there itself.
Stateful session beans lets u allow to spawn the bean managed transaction across methods. you can begin your transaction in one method and end it in a differnt method or you can end the transaction after calling the methods.
The problem you are dealing with can typically very well handled by writing bean managed transaction.
Hope this helps. If you need anymore clarity on my solution, please let me know.
-amit

"Sharing" a stateful session bean between two servlets, beans

Hello!
I just started to learn some java ee programming and was wondering how i would share one stateful session bean between two servlets.
I created the bean with @Stateful.
I tried to inject the stateful bean in both servlets by @EJB and i can manipulate the object, but each servlet seems to have its own object.
The bean has a remote interface that it implements.
What i also tried was to add the mappedName to the @Stateful expression. Something like: @Stateful(mappedName="name") and to use the bean by @EJB(mappedName="name") but it had no effect.
Im using glassfish 2.1 with netbeans 6.7.1 as my environment (standard settings)
dummy question, but i googled like hours and couldnt find anything : \
hope someone can help and sorry for my bad english
greets and thanks

Hi there!
I think you are searching for something like an application wide singleton. There is the possibility to define such one in the Glassfish admin console.
Hope this helps!

Stateful Session Bean accesed by two JSPs.

Hi there,
We are having quite an issue; we have an application that stores session
state in an stateful session bean. And we have noticed some parts of the
application create a situation where is possible that two frames -and so two
jsp- access the session bean at the same time. And, of course, it´s going to
be the same instance of the session bean..... what will be the behaviour in
this case?. Will the requests be serialized, an exception will be thrown or
the EJB will be destroyed?. Not very sure of what would happen. I suppose
there could be some problems with this-. I would appreciate any help.
Many thanks. Best regards.

Hrm. EJB spec is quite clear on what will happen (RemoteException thrown) if
the second client attempts to use Stateful Session bean which is already in
use (and the bean will not be destroyed - container will simply throw an
exception after failing to acquire a lock on the bean instance without waiting
(allow-concurrent-calls option in WebLogic allows client call to wait to acquire
lock - this was probably added as a convinience feature for applications which
use frames)).
So, normally your application has to ensure that no 2 clients are able to use
the same stateful session bean concurrently, or use allow-concurrent-calls option,
which will do that for you, but the application will become non portable.
Dimitri
PS: Thanks. Maine Coon cats are the best. Ours is a 22-pound giant ;-)
Pinklon Thomas <[email protected]> wrote:
Hi Dimitri,
Thnaks a lot for the help:one thing that I do not know if it´s an issue is
that calls come from different JSPs; the strategy I have seen in another Web
application servers is trying to activate the EJB in the middle of another
transaction... In this situation, the container cannot activate the EJB,
roolback the transaction and destroys the EJB.... Would Weblogic feature
avoid this?. I will investigate on my part....
Many many thnaks. Nice cats.
"Dimitri Rakitine" <[email protected]> wrote in message
news:[email protected]...
In 6.1 you can set allow-concurrent-calls to true in this situation:

Pinklon Thomas <[email protected]> wrote:
Hi there,
We are having quite an issue; we have an application that stores
session
state in an stateful session bean. And we have noticed some parts of the
application create a situation where is possible that two frames -and sotwo
jsp- access the session bean at the same time. And, of course, it´sgoing to
be the same instance of the session bean..... what will be the behaviourin
this case?. Will the requests be serialized, an exception will be thrownor
the EJB will be destroyed?. Not very sure of what would happen. Isuppose
there could be some problems with this-. I would appreciate any help.
Many thanks. Best regards.--
Dimitri

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.

Help!!! Stateful session bean clustering

Similar Messages

Maybe you are looking for