Cluster and Session EJB replication

          I have a dedicated Weblogic 5.1 box running with SP 6 serving up JSP and Servlets.
          The Servlets do look ups for session EJBs, which are hosted on a separate box behind
          a firewall. My question is:
          If I implement clustering of the JSP/Servlet Weblogic Instance so that I have four machines in a cluster,
          does Weblogic 5.1 or 6.0 replicate the handle to the session EJB's stub only so that in case server 1 crashes,
          Server 2 will be able to retrieve a handle to the session EJBs?
          Thanks,
          Paul Richardson

If the handle is in the HttpSession, then the handle will be replicated. If
          the EJB server fails over in WL 5.1, the stateful session EJBs will be lost.
          WL 6.0 supports statefull session EJB replication for failover, but I
          suggest that you not use it unless you have a specific architectural reason
          to.
          Cameron Purdy
          Tangosol, Inc.
          http://www.tangosol.com
          +1.617.623.5782
          WebLogic Consulting Available
          "Paul Richardson" <[email protected]> wrote in message
          news:[email protected]..
          >
          > I have a dedicated Weblogic 5.1 box running with SP 6 serving up JSP and
          Servlets.
          > The Servlets do look ups for session EJBs, which are hosted on a separate
          box behind
          > a firewall. My question is:
          >
          > If I implement clustering of the JSP/Servlet Weblogic Instance so that I
          have four machines in a cluster,
          > does Weblogic 5.1 or 6.0 replicate the handle to the session EJB's stub
          only so that in case server 1 crashes,
          > Server 2 will be able to retrieve a handle to the session EJBs?
          >
          >
          > Thanks,
          > Paul Richardson

Similar Messages

Cluster Server: Session bean replication

I am using JDeveloper 11.1.1.6.0
I am currently trying to prepare our application for a clustered environment, and I was following section 20.4.3 of the following document: http://docs.oracle.com/cd/E23943_01/web.1111/b31974/web_getstarted.htm#CHDIJCIE
The document mentions that I need to make view, pageflow, and session scope beans as "serializable" and that view and pageflow scope beans need to be marked as dirty when they are updated. However, session bean was not included in needing to be marked. Do I need to do something else in order to ensure that the changes made to the session scope are replicated across the cluster? Or does ADF somehow detect that there was a change and handle this replication for me?
Thank you.

The reason you only need to do this for view and pageflow scope beans is the way they are stored. These scopes are stored as maps in the session scope. If you alter a bean inside the map the session scope don't know it as it only knows the reference and not the value.
Changes to session scope objects are tracked by the framework.
Timo

How to ensure singleton behavior across cluster and session?

I need a class that loads up properties from a file and keeps those properties loaded after the first load? The code that will do the loading is being invoked by jsp. I have defined all the methods and variables as static and have a static flag to check if loaded. Is that sufficient?

You could scope such info to the application scope - some info is provided here: http://java.sun.com/products/jsp/tags/11/syntaxref11.fm14.html
"application - You can use the Bean from any JSP page in the same application as the JSP page that created the Bean. The Bean exists across an entire JSP application, and any page in the application can use the Bean."

Session State Replication of Referenced Objects

Here is question on Clustering and Session state replication:
          Scenario:
          Consider two Session Objects A and B.
          Object A has-a reference to object B.
          So whatever changes done to Object B is reflected in Object A.
          In-memory Session replication happens on every HttpSession.setAttribute() call.
          The question is will the two session objects(A and B) be replicated to the other cluster and will still maintain the reference relationship or will they be two separate objects with same data (in different memory locations).
          regards,
          Jaiganesh

Ok, I have been meaning to dig into session replication in a bit more detail and your question is a good excuse to do it!
          First stop the docs:
          Bea Docs
          The bits that jump out are under:
          Programming Considerations for Clustered Servlets and JSPs
          1) Session Data Must Be Serializable, so both your objects are serializable.
          2) Use setAttribute to Change Session State In an HTTP servlet that implements javax.servlet.http.HttpSession, use HttpSession.setAttribute (which replaces the deprecated putValue) to change attributes in a session object. If you set attributes in a session object with setAttribute, the object and its attributes are replicated in a cluster using in-memory replication. If you use other set methods to change objects within a session, WebLogic Server does not replicate those changes. Every time a change is made to an object that is in the session, setAttribute() should be called to update that object across the cluster.
          Likewise, use removeAttribute (which, in turn, replaces the deprecated removeValue) to remove an attribute from a session object.
          >Will the reference as shown in the step 3 will be >maintained after replication on the other cluster ?? I >guess not!!
          I don't understand "on the other cluster" There is normally one cluster made up of a few servers. The session state is maintained on one primary server and a secondary server. So you have aObj.a2 = bObj, from the docs I would understand that at the momment you called session.setAttribute the aObj and all its fields provided they are seriliazable will be replicated in Mememory.
          >There the aObj and bObj stored in the two different >session objects will not have a reference relationship >in other words if i change bObj on the other cluster >will the reference a2 of aObj be able see it ??
          This is testing the limits of my understanding, but would have thought if the objects are in different sessions they should not be able to reference each other in the manner I think you are suggesting, so if I access aObj.a2 (an instance of bObj) and changed it in one session it should not affet any other bObj unless bObj is a singleton....I think!
          What say you?

Re: User Session using ServletSession and Stateful EJB in Cluster

          Sorry , I didn't use WLS 6.0, we use wls 5.1 in production.
          But in Wls 6.0, in some situations , the state of the stateful session bean can be lost. So it's not so reliable. You have to deal with it in the client code. Instead, servlet is a reliable solution.
          In order to test under wls6.0, you can store the handle of the EJBObject in the HttpSession, not in jndi, cos if the instance fails, all its objects will be removed by remaining instances from jndi. In another instance, you get the handle, and try to get the EJBObject.
          In wls5.1, some information like the server url must be embeded inside the handle. But in wls6.0, I don't know how they deal with it.
          I am looking forward to your results
          "Anuj Soni" <[email protected]> wrote:
          >
          >What kind of clustering problems you had with WL6.0 for Stateful session beans ? It will be helpful for me to know before hand.
          >
          >BTW, how were you able to test stateful session beans in a cluster under WL6.0 i.e. were you storing the Handle or EJBObject in HttpSession or did you store it in JNDI ?
          >
          >Thanks,
          >
          >Anuj
          >"Tao Zhang" <[email protected]> wrote:
          >>Although it's very advanced to take advantage of both http session and
          >>stateful session bean replication, but if you rely on the stateful session
          >>bean's state, you will be in trouble. Because the support of stateful
          >>session bean's replication is not perfect in wls6.0. We already chaned
          >>almost all stateful session beans into servlets or entity beans.
          >>
          >>I am not sure about the handle of the EJBObject. I think it should be able
          >>to reconstruct for us otherwise we can't use the handle any more.
          >>
          >>You can do a test. BTW, could you tell me the result?
          >>
          >>Thanks.
          >>
          >>Anuj Soni <[email protected]> wrote in message
          >>news:[email protected]...
          >>>
          >>> Hi,
          >>>
          >>> I am designing the workflow for my web application using a Stateful
          >>session bean. As Weblogic 6.0 supports clustering of stateful session bean
          >>and HttpSession(in-memory replication), I want to use the combination of
          >>both techniques to provide load-balancing and fail-over safety for user
          >>sessions and their corresponding workflows.
          >>>
          >>> The question I have is that, Is Handle obtained using
          >>EJBObject.getHandle(), fail-over safe (for a clusterable stateful bean), so
          >>that I can reconstruct the reference to EJBObject on the secondary server
          >>incase of primary server crash.
          >>>
          >>> My understanding is that I should store Handle in the HttpSession as it is
          >>Serializable not the EJBObject. The weblogic 6.0 document only talks about
          >>the replica-awareness of EJBObject.
          >>>
          >>> If my above assumption is incorrect, Can you tell me how else I can
          >>achieve my goal ?
          >>>
          >>> Thanks in advance.
          >>>
          >>> Anuj Soni
          >>
          >>
          >


Any one tested this scenario yet? i.e: storing the handle to an EJB object and then trying to re-use after the HttpSession is restored?
          Thanks.

Failover for a stateful session EJB on a two node cluster results in java.io.StreamCorrupedException

          Stateful session EJB is deployed on cluster members A and B. Client calls a method
          on the bean and the request is routed to server A, then A is shut down. The client's
          next method invocation is routed to server B where the bean's state has been replicated.
          Server A re-joins the cluster and B is shut down, the request routed to A results
          in the following:
          java.rmi.NoSuchObjectException: Activation failed with: java.io.StreamCorruptedException:
          InputStream does not contain a serialized object
          at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:849)
          at java.io.ObjectInputStream.<init>(ObjectInputStream.java:168)
          at weblogic.common.internal.ReplacerObjectInputStream.<init>(ReplacerObjectInputStream.java:33)
          at weblogic.common.internal.ReplacerObjectInputStream.<init>(ReplacerObjectInputStream.java:43)
          at weblogic.common.internal.ReplacerObjectInputStream.<init>(ReplacerObjectInputStream.java:54)
          at weblogic.ejb20.swap.PassivationUtils.read(PassivationUtils.java:50)
          at weblogic.ejb20.swap.ReplicatedMemorySwap.read(ReplicatedMemorySwap.java:111)
          at weblogic.ejb20.manager.StatefulSessionManager.getBean(StatefulSessionManager.java:178)
          at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:236)
          at weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:113)
          at weblogic.ejb20.internal.StatefulEJBObject.preInvoke(StatefulEJBObject.java:148)
          at com.access360.enrole.apps.ejb.organization.SearchManagerBeanEOImpl.findAllPeople(SearchManagerBeanEOImpl.java:644)
          at com.access360.enrole.webclient.organization.person.PeopleList.getPeople(PeopleList.java:148)
          at com.access360.enrole.webclient.organization.person.PeopleListServlet.constructPeopleListXML(PeopleListServlet.java:284)
          at com.access360.enrole.webclient.organization.person.PeopleListServlet.service(PeopleListServlet.java:238)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:213)
          at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:275)
          at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:183)
          at com.access360.enrole.webclient.organization.person.SubmitPersonAddServlet.forwardToPeopleList(SubmitPersonAddServlet.java:134)
          at com.access360.enrole.webclient.organization.person.SubmitPersonAddServlet.service(SubmitPersonAddServlet.java:114)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:213)
          at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:1265)
          at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:1631)
          at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          We are certain that the EJB's entire object graph is Serializable. Any comments on
          this failover scenario?
          Alex Rodriguez
          Software Engineer, Access360
          [email protected]


          Rajesh,
          Thanks for the reply. We are running WL 6.0 SP2 with RP3. We cannot reproduce it
          consistently. In your reply you mention "... and EJB handles". Does that refer to
          another patch?
          As for the code, we will run tests with a scaled down version of the stateful bean
          and a simple client servlet. I will post the code asap. The high level call sequence
          is: servlet service() -> lookup ejb home -> get cluster aware stub from home -> put
          bean handle in http session -> call bean method -> server A goes down -> next call
          to the bean -> get handle from replicated http session -> get bean from handle ->
          request is routed to server B. java.io.StreamCorruptedException is thrown, sometimes,
          when server A re-joins the cluster and a request is routed to it (i.e. server B is
          shut-down). One thing I did not mention is that the bean is deployed on server A,
          and server A is also the Admin server. We are considering not using the Admin server
          to deploy the bean, however, but will add another Managed server.
          Will contact support about CR073917: can it be applied to WL 6.0 SP3 with RP3?
          Regards,
          Alex J. Rodriguez
          Rajesh Mirchandani <[email protected]> wrote:
          >
          >Alex,
          >
          >Are you able to consitently reproduce this? Could you post your code here?
          >
          >What version of the Server with Service pack are you using?
          >
          >If you are using WLS 6.1SP2 and EJB handles contact support and get a patch
          >for CR073917.
          >
          >
          >"Alex J. Rodriguez" wrote:
          >
          >> Stateful session EJB is deployed on cluster members A and B. Client calls
          >a method
          >> on the bean and the request is routed to server A, then A is shut down.
          >The client's
          >> next method invocation is routed to server B where the bean's state has
          >been replicated.
          >> Server A re-joins the cluster and B is shut down, the request routed to
          >A results
          >> in the following:
          >>
          >> java.rmi.NoSuchObjectException: Activation failed with: java.io.StreamCorruptedException:
          >> InputStream does not contain a serialized object
          >> at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:849)
          >> at java.io.ObjectInputStream.<init>(ObjectInputStream.java:168)
          >> at weblogic.common.internal.ReplacerObjectInputStream.<init>(ReplacerObjectInputStream.java:33)
          >> at weblogic.common.internal.ReplacerObjectInputStream.<init>(ReplacerObjectInputStream.java:43)
          >> at weblogic.common.internal.ReplacerObjectInputStream.<init>(ReplacerObjectInputStream.java:54)
          >> at weblogic.ejb20.swap.PassivationUtils.read(PassivationUtils.java:50)
          >> at weblogic.ejb20.swap.ReplicatedMemorySwap.read(ReplicatedMemorySwap.java:111)
          >> at weblogic.ejb20.manager.StatefulSessionManager.getBean(StatefulSessionManager.java:178)
          >> at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:236)
          >> at weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:113)
          >> at weblogic.ejb20.internal.StatefulEJBObject.preInvoke(StatefulEJBObject.java:148)
          >> at com.access360.enrole.apps.ejb.organization.SearchManagerBeanEOImpl.findAllPeople(SearchManagerBeanEOImpl.java:644)
          >> at com.access360.enrole.webclient.organization.person.PeopleList.getPeople(PeopleList.java:148)
          >> at com.access360.enrole.webclient.organization.person.PeopleListServlet.constructPeopleListXML(PeopleListServlet.java:284)
          >> at com.access360.enrole.webclient.organization.person.PeopleListServlet.service(PeopleListServlet.java:238)
          >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          >> at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:213)
          >> at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:275)
          >> at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:183)
          >> at com.access360.enrole.webclient.organization.person.SubmitPersonAddServlet.forwardToPeopleList(SubmitPersonAddServlet.java:134)
          >> at com.access360.enrole.webclient.organization.person.SubmitPersonAddServlet.service(SubmitPersonAddServlet.java:114)
          >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          >> at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:213)
          >> at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:1265)
          >> at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:1631)
          >> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
          >> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          >>
          >> We are certain that the EJB's entire object graph is Serializable. Any
          >comments on
          >> this failover scenario?
          >>
          >> Alex Rodriguez
          >> Software Engineer, Access360
          >> [email protected]
          >

Session state replication taking time to replicate in weblogic cluster

I have a application fully serialized code with WEB-INF/lib containing the below configs with Unicast communication.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">
<weblogic-web-app>
<session-descriptor>
    <session-param>
      <param-name>TimeoutSecs</param-name>
      <param-value>1800</param-value>
    </session-param>
                <cookie-http-only>false</cookie-http-only>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
                </session-descriptor>
</weblogic-web-app>
OHS plugin is having below config
LoadModule weblogic_module   "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"
<IfModule mod_weblogic.c>
WebLogicCluster 172.12.113.141:7006,172.12.113.140:7006
        MatchExpression /finapp/*
</IfModule>
And weblogic cluster is replicating session instantly when ever there is some activities happening in the application.
It is having a problem only in below scenario when the session is open but the user is not doing anything.
I have 2 nodes in the cluster if one goes down(currently request serving one) it is failing over to the next but the session is not getting copied instantly. Below is the scenario where it works fine and where the replication is delayed.
1. Both servers(server1,server2) up for some time and user logs in and is continuing work.
2. primary server(server1) crashes in middle, secondary(server2) will take over the existing session and you will see user will be continuing the work without any issues(no logouts).
3. After sometime server1 comes up online, user keeps on testing(clicking some tab which makes a request to server), you will see the server1 will have a replica of server2 instantly.
4. You can bring down the server2 now and you will see the users session will not interrupt and user will be able to continue session with the server1.
Now coming to the scenario where you will be able to delayed replication :
1. Both servers up and user logged in and started work.
2. Primary server(server1) goes down and secondary server(server2) will take over the session and let the user continue its work without any logout.
2. server1 comes back online and user is not doing anything(no clicks) with application just kept the session open and server2(primary session) goes down within the replication time then the user will get logged out and might see some erratic behavior in any applications deployed to that weblogic. (We saw that if we dont shutdown server2 immediately(within 1min) and wait for 5mins+ weblogic is copying the session from server2 to server1. After that copy if we shutdown the primary server(server2) user is not having any issues)
To summerize if a session is active(logged in) and some activity(clicking) is going on then replication is happening instantly from primary to secondary but if the user is active(logged in) and not doing anything(not clicking) then the session from primary to secondary is taking 5minutes+
Please let me know if there is some weblogic configs to check to reduce this time lag and let weblogic copy the session continuously either the user is performing any activity or not in the logged in session.
Thanks,

Hi,
This is the expected behavior. Please take a look at this document: WebLogic Server - Session Replication/Failover Scenario When Only One Server In Cluster is RUNNING (Doc ID 1292033.1)
In a WebLogic Server domain, with a Cluster of 2 Managed Servers and a web application deployed on this Cluster, you have only one managed server running and then you make a request through a proxy server to access the application.
The default cookie which is JSESSIONID will be created something like
<SessionID>!<PrimaryJVMID>!NONE
Here, you see the secondary server as NONE as there is only one server in cluster running.
Now, you leave HTTP session idle, meaning there will be no activity and requests in it.
Now, you bring up the second managed server instance in the cluster. The JSESSIONID for the earlier created HTTPSession will be unchanged: still
<SessionID>!<PrimaryJVMID>!NONE
unless there are any requests made or activity in it.
At this point of time, if there is a failure of the Managed server, the idle in-flight HTTP Sessions which were created earlier when this managed server was RUNNING, will be dropped and there will be no failover. Only active HTTP Sessions which have a secondary JVM ID will be failed over to the secondary managed server.
At any point, if subsequent requests are made and if any activity is made to the Idle HTTP sessions which were earlier created, the JSESSIONID gets updated with the secondary JVMID and sessions gets replicated and failed over in case of server crash.

Session ejb 3.0 stateful and same instance

Hello,
I'm using OC4J 10.1.3.3 and EJB 3.0/JSP
In a jsp I do two different lookup for a STATEFUL
session ejb 3.0, and I want two different instances
of the ejb, instead I get the same one...
Please help. Thanks.

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.

EJB - MDB and Session and Entity - Seem to always run under same Thread

I am working on an application that implemets a connection from an MDB to a Session EJB which inturn connects to a Entity EJB. All connections are impemented as Local Home. I use log4j for tracing and notice that the thread ID reported for all activity is the same "Thread ID: MessageListenerThreadPool : 0" .
This confuses me because I thought that all EJB's would execute under different threads. Have I done something wrong? Have I missinterpreted the EJB implementation? Any opinions would be greatly appreciated!!

Hi Kelly,
This is a slight misinterpretation of the EJB threading requirements. There are a couple different issues as play here. First, the main threading guarantee made by the spec is that a particular instance of an EJB will not be invoked by the container on more than one thread at a time. This is one of the guarantees that simplifies the EJB programming model so that developers don't have to do anything special (e.g. the use of synchronized blocks) to handle concurrent access. Second, the EJB Local programming model requires that invocations have pass-by-reference semantics. Of course, the easiest way for the container to provide that behavior is to literally make the local invocation on the same thread.
The call-flow you're describing touches a single instance from three different beans, so the threading guarantee is not violated. Hope that clears things up a bit.
--ken

Correct Principal not showing up in the Session and Entity EJB layer

In our app a user is authenticated via the web container. The web layer then makes
calls to various session EJB's.
In our session bean, calls to sessionContext.getCallerPrincipal().getName() sometimes
returns "SYSTEM" instead of
the principal's name that was authenticated at the web container level.
In our entity beans, calls to entityContext.getCallerPrincipal().getName()
sometimes returns "<anonymous>" instead of the principal's
name.
A) Why isn't the principal's name = context's principal's name?
B) Can we ensure that principal's name isn't lost?
As per the documentation, the user principal is associated with the current thread,
so why is it that when calls are made in the same thread of execution from the
web layer to the EJB layer we are losing the right principal. Btw, the Principal
is always correct in the Web layer. We do not have any RunAs options set in our
EJB deployment descriptors.
What are we doing wrong?

You aren't doing anything wrong. This is a bug in the webservices.
kapil khanna wrote:
In our app a user is authenticated via the web container. The web layer then makes
calls to various session EJB's.
In our session bean, calls to sessionContext.getCallerPrincipal().getName() sometimes
returns "SYSTEM" instead of
the principal's name that was authenticated at the web container level.
In our entity beans, calls to entityContext.getCallerPrincipal().getName()
sometimes returns "<anonymous>" instead of the principal's
name.
A) Why isn't the principal's name = context's principal's name?
B) Can we ensure that principal's name isn't lost?
As per the documentation, the user principal is associated with the current thread,
so why is it that when calls are made in the same thread of execution from the
web layer to the EJB layer we are losing the right principal. Btw, the Principal
is always correct in the Web layer. We do not have any RunAs options set in our
EJB deployment descriptors.
What are we doing wrong?

Session state replication

Hi.
Has anyone got the session replication in OC4J to work
on Windows 2000?
We're running a 9.0.2 infrastructure and two clustered
9.0.3 9iAS application servers, that are supposed to
replicate HTTPServletSession state.
We are using the default_island on a separate OC4J
instance that are configured via Enterprice Manager to
use multicast IP 230.0.0.1 and port 9127 (default).
The tag <cluster-config/> is present in the file
orion-web.xml and the <distributable/> tag is present in
the web.xml in the WAR-file.
No EJBs are used - only JSPs and servlets.
Any suggestions?
Thanks!
Jesper

Hi,
This is the expected behavior. Please take a look at this document: WebLogic Server - Session Replication/Failover Scenario When Only One Server In Cluster is RUNNING (Doc ID 1292033.1)
In a WebLogic Server domain, with a Cluster of 2 Managed Servers and a web application deployed on this Cluster, you have only one managed server running and then you make a request through a proxy server to access the application.
The default cookie which is JSESSIONID will be created something like
<SessionID>!<PrimaryJVMID>!NONE
Here, you see the secondary server as NONE as there is only one server in cluster running.
Now, you leave HTTP session idle, meaning there will be no activity and requests in it.
Now, you bring up the second managed server instance in the cluster. The JSESSIONID for the earlier created HTTPSession will be unchanged: still
<SessionID>!<PrimaryJVMID>!NONE
unless there are any requests made or activity in it.
At this point of time, if there is a failure of the Managed server, the idle in-flight HTTP Sessions which were created earlier when this managed server was RUNNING, will be dropped and there will be no failover. Only active HTTP Sessions which have a secondary JVM ID will be failed over to the secondary managed server.
At any point, if subsequent requests are made and if any activity is made to the Idle HTTP sessions which were earlier created, the JSESSIONID gets updated with the secondary JVMID and sessions gets replicated and failed over in case of server crash.

WLS Express and in-memory replication

          I will be purchasing WLS and or WLS Express. I'm looking at using Zeus as my Web Server and then using the Apache-Proxy Plugin for redirecting dynamic content to my Web-Cluster.
          Question: Can WebLogic Express do clustering and in-memory session replication? If so I would be very intrested. We will be migrating our business logic into EJB's soon enough but I have a proof of concept comming up real quick and I I could use WLS Express for my Web-Cluster and then use the more "Expensive" but robust App-Server in the back I would simply love it!
          Please help me:)
          the Viking!


XMLViking wrote:
          >
          > Rob,
          >
          > Thanks for the rapid response. I had conducted a little research later today and arrived at the same conclusion. So it's my understanding that you create the in-memory replication through the usage of the Proxy-Plug in and the usage of a Replication Group?
          >
          Basically, yes. The docs should cover this in detail.
          > BEA mentions a considerable overhead for the serialization of the servlets session state? Does anyone have any data on the latency we are talking about here? Does this even begin to compare with the costs of a JDBC call for session retrieval from a DB?
          >
          For most applications, the in-memory rep performance should be very
          good. In the benchmarks I've seen, it approaches the performance of
          using no session persistence. JDBC adds quite a bit of overhead.
          The in-memory rep performance is proportional to how much data you are
          sending across the wire. In general, I would not recommend huge
          sessions.
          -- Rob
          > Thank you very much!
          >
          > Rob Woollen <[email protected]> wrote:
          > >XMLViking wrote:
          > >>
          > >> I will be purchasing WLS and or WLS Express. I'm
          > >> looking at using Zeus as my Web Server and then
          > >> using the Apache-Proxy Plugin for redirecting
          > >> dynamic content to my Web-Cluster.
          > >
          > >Zeus is not currently a supported web server, but I believe Zeus
          > >supports NSAPI so our Netscape plug-in may work.
          > >
          > >>
          > >> Question: Can WebLogic Express do clustering and
          > >> in-memory session replication? If so I would be very
          > >> intrested. We will be migrating our business logic
          > >> into EJB's soon enough but I have a proof of concept
          > >> comming up real quick and I I could use WLS Express
          > >> for my Web-Cluster and then use the more "Expensive"
          > >> but robust App-Server in the back I would simply
          > >> love it!
          > >
          > >You can purchase WebLogic Express with clustering support. Essentially
          > >you get the in-memory replication of servlet session state.
          > >
          > >Contact your sales representative or [email protected] for more info.
          > >
          > >-- Rob
          > >
          > >>
          > >> Please help me:)
          > >>
          > >> the Viking!

A CONFUSION:The difference between cluster and multi-IP--DNS mapping??

          I have a test about simplest cluster,admin and managed server all told me "start
          cluster service"!the two IP address use ONE DomainName,If one down,when I send
          request with dn,It first look up admin server,no found and then go dns to search
          another server,about one minute then the server send response to me!
          But when I do not config a cluster,only start two admin server and give them the
          same dns,the same appearance as cluster!
          I don't understand the difference between cluster and multi-IP--DNS mapping??


          <[email protected]> wrote in message news:3b16f1db$[email protected]..
          |
          | I have a test about simplest cluster,admin and managed server all told me
          "start
          | cluster service"!the two IP address use ONE DomainName,If one down,when I
          send
          | request with dn,It first look up admin server,no found and then go dns to
          search
          | another server,about one minute then the server send response to me!
          |
          This is DNS fail-over.
          | But when I do not config a cluster,only start two admin server and give
          them the
          | same dns,the same appearance as cluster!
          | I don't understand the difference between cluster and multi-IP--DNS
          mapping??
          It is totally different. regarding the last failover example you've given,
          of course the 2 servers can have identical files maintained under
          public_html. DNS will failover requests to "foo.html" to the other one if
          the first server is down, but if you have something saved in a session, say
          shopping cart example, it's totally lost, but with WLS clustering, the
          session is replicated to the other server in the cluster, you may just
          check-out, don't have to order again.
          This is just a simple example of WLS cluster session-replication. WLS
          supports EJB, RMI Objects, JMS (6.0) clustering.. check the doc at
          http://www.weblogic.com/docs50/cluster/index.html

Cluster and commons-logging jar LogConfigurationException

Hi,
My configuration:
-OAS 10.1.3.1 on 2 machines with oracle cluster configuration (discovery).
My app:
-ear which includes simple ejb3 module with commons-logging-1.1.jar lib (Jakarta commons logging)
-clustering and replication is configured (in orion-application.xml):
<cluster allow-colocation="false">
     <replication-policy trigger="onSetAttribute" scope="allAttributes" />
     <flow-control-policy enabled="false" />
     <protocol>
          <peer>
               <opmn-discovery />
          </peer>
     </protocol>
</cluster>
When I'm trying to deploy my application I always get an error during deployment:
[19-Jun-2007 16:46:44] Initializing ClassLoader(s)
[01-Jan-1970 01:00:00] Error deserializing return-value: org.apache.commons.logging.LogConfigurationException; nested exception is: java.lang.ClassNotFoundException: org.apache.commons.logging.LogConfigurationException
It doesn't matter if I try to deploy it on one or both machines. The exception is always the same on each machine.
When I get rid of clustering/replication configuration (from orion-application.xml or during deployment) application is deployed without any problem.
Also when I remove commons-logging-1.1.jar application is deployed.
I know that there is already apache.commons.logging 1.0.4 in OAS shared libraries by it's not selected in "Configure Class Loading" by default.
I also tried use the same version (1.0.4) in my app - didn't help.
I can also deploy without any problem war file or ear file with web module, which has commons-logging-1.1.jar. But not ejb!
Any advice?
Thanks
darek

Hey Darek -- I just gave it a quick try -- the ListQueries query works as expected.
This is how I executed it and the results it returned.
d:\java\oc4j-10131-prod\j2ee\home>java -Doc4j.start.query=ListQueries+Exit -jar oc4j.jar
07/06/25 00:51:41 Shutting down OC4J...
AuditLoader - Performs various diagnostics on the contents of the speci
fied loader(s).
Callers - List all classes that call the specified method(s).
ClassLoadMetrics - Report metrics from specified loader(s) or all if none specified.
ClassPath - List the code-sources in use.
Dependencies - List the dependencies of the specified class.
Depends - List all classes that depend on the specified class(s).
DuplicateClasses - List duplicate classes, both loaded and in code-sources.
DuplicateCodeSources - List code-sources that have more than 1 subscriber, or the same name.
Exit - Exits the process (does shutdown if system is running).
FindResource - List the code-sources containing the specified resource.
GetResource - Call getResource() or getResources() on a specified loader and report the results.
HttpSessions - View summary of active HttpSessions for deployed applications.
LeakedLoaders - Control detection of class loader leaks and inspect results.
ListQueries - List built-in subclasses of the "oracle.classloader.query.Query" class.
LoadClass - Call loadClass() or Class.forName() using a specified loader and report the results.
LoadedClasses - List the names of all loaded classes (if available).
LoaderTree - List the class loader tree.
Packages - List the package names contained within the specified code-source(s).
SharedLibraries - List shared-libraries and the loaders that have imported them.
SystemProperties - List or set System properties.
ThreadPools - List application server related thread for the current VM.
Threads - List thread info for the current VM.
UnusedCodeSources - List any code-sources from which no classes or resources have been loaded.
Uptime - Report how long the system has been running.
VMStat - List statistic info for the current VM.
Specify the query name for a full description, or use the '-l' option to see ful
l descriptions for all.

Stateless session EJBs & "idempotent"

We need to declare a method as "idempotent" to take care of failure inside a
          method call, For that to work the code inside should written in such way so
          that repeated call to the same method should not give us diffrent result.
          But why can't weblogic implement a partial rollback( Just like Oracle's save
          point rollback, where you can rollback to certain point within a
          transaction).
          Because some times it is not possible to code in such a way to get the same
          result every time(Incase of fail over)
          Thanks
          ,Stateless session EJBs
          Stateless session EJBs can have both a cluster-aware home stub and a
          replica-aware EJBObject stub. By default, WebLogic Server provides failover
          services for EJB method calls, but only if a failure occurs between method
          calls. For example, failover is automatically supported if there is a
          failure after a method completes, or if the method fails to connect to a
          server. When failures occur while an EJB method is in progress, WebLogic
          Server does not automatically failover from one server to another.
          This default behavior ensures that database updates within an EJB method are
          not "duplicated" due to a failover scenario. For example, if a client calls
          a method which increments a value in a datastore and WebLogic Server fails
          over to another server before the method completes, the datastore would be
          updated twice for the client's single method call.
          If methods are written in such a way that repeated calls to the same method
          do not cause duplicate updates, the method is said to be "idempotent." For
          idempotent methods, WebLogic Server provides the
          stateless-bean-methods-are-idempotent deployment property. If you set this
          property to "true" in weblogic-ejb-jar.xml, WebLogic Server assumes that the
          method is idempotent and will provide failover services for the EJB method,
          even if a failure occurs during a method call.


Vishal,
I wouldn't think you would have a problem doing RMI communication from a Entity
Bean - - for instance, when a WLS instance 'hosts' an EJB that communicates to
a different WLS instance that 'hosts' an EJB that communication occurs via RMI.
Chuck Nelson
Developer Relations Engineer
BEA Technical Support

Cluster and Session EJB replication

Similar Messages

Maybe you are looking for