Clustered session state replication

          We are new to WebLogic, vrs 8.1 server, and are trying to get session states to
          replicate within a cluster. We believe everything is set up per the Bea docs but
          in the end "the state" on the secondary does not seem to exist, or we do not know
          how to see it.
          Our environment:
          A domain with one admin server and four managed servers on a Sun server. Three
          of the managed servers are in a cluster, the fourth is the proxy server dispatching
          to the cluster using WebLogic HttpCluteredServlet. The app deployed to the cluster
          has the weblogic.xml session parameter for PersistentStoreType set to replciated.
          Everything runs fine till the end: A call to the app is received at the ProxyServer
          and is routed to a server in the cluster. The servlet creates a session object
          for the user. When the user executes the servlet a second time the session object
          is updated and a count is displayed to the user for each subsequent hit to the
          servlet. The session object (a java object) is serialized. Then we kill the primary
          server that is used to comunicate with the user requests. The proxyServer then
          directs the user to a different server within the cluster as it should, but the
          session object from the primary server (now killed) does not appear to be on the
          new server since a new session object gets created.
          Any ideas?

Warren Anderson wrote:
          > We are new to WebLogic, vrs 8.1 server, and are trying to get session states to
          > replicate within a cluster. We believe everything is set up per the Bea docs but
          > in the end "the state" on the secondary does not seem to exist, or we do not know
          > how to see it.
          >
          > Our environment:
          >
          > A domain with one admin server and four managed servers on a Sun server. Three
          > of the managed servers are in a cluster, the fourth is the proxy server dispatching
          > to the cluster using WebLogic HttpCluteredServlet. The app deployed to the cluster
          > has the weblogic.xml session parameter for PersistentStoreType set to replciated.
          >
          > Everything runs fine till the end: A call to the app is received at the ProxyServer
          > and is routed to a server in the cluster. The servlet creates a session object
          > for the user. When the user executes the servlet a second time the session object
          > is updated and a count is displayed to the user for each subsequent hit to the
          > servlet. The session object (a java object) is serialized. Then we kill the primary
          > server that is used to comunicate with the user requests. The proxyServer then
          > directs the user to a different server within the cluster as it should, but the
          > session object from the primary server (now killed) does not appear to be on the
          > new server since a new session object gets created.
          >
          > Any ideas?
          Did you make sure everything in the session is serializable or remote?
          -- Prasad

Similar Messages

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?

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.

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.

CF7 Clustering - session replication broken

Further to my
earlier
thread on CF7 clustering and the "network error",
I think session replication is broken. True, I can't find any
documentation which explains how it is supposed to behave, but this
is what I'm seeing:
If you have a two node cluster, and person A has a session on
node 1 and person B a session on node 2, session variables for each
user DO NOT appear on both nodes
Sessions on one node will only appear on the other when the
first node fails over
Moreover, they will only appear when the user makes another
request
CFLOGIN, when using loginstorage="session" does not replicate.
This means you have to use sticky sessions, and if there is a node
failure, the user will have to login in again. This can be avoided
by using loginstorage = "cookie" but this means the username and
password are stored unencrypted in the cookie.
Problems I have with this:
It's impossible to have a cluster wide view of sessions. E.g.
you can't count how many sessions you have at any one time. Any
code that makes use of being able to dig in to multiple sessions -
made possible by J2EE sessions - will not work reliably.
CFLOGIN is broken. It would be better to not use it for sites
that have to be secure as keeping the unencrypted username and
password in a cookie is very insecure. The only way to protect the
username and password being stored in the cookie is SSL; and that
means that every single item on the site needs to be protected by
SSL to stop the browser from serving up the cookie over an
unprotected connection.
It's not clear what is responsible for replication. If sessions
are only replicated when an instance goes down, rather than
continously, then I assume that the master instance of CF on each
server is responsible for replication. What happens if the server
crashes?

Information about session replication can be found here: http://docs.oracle.com/cd/E21764_01/web.1111/e13709/failover.htm#i1024620
it contains a section 'Requirements for HTTP Session State Replication' that might be helpful to you.
Also important to note is, how the load balancer handles session binding and the WebLogic cookie
http://docs.oracle.com/cd/E21764_01/web.1111/e13709/load_balancing.htm#i1026939

ClassNotFoundException trying to replication session state...

          Help! This has been bugging me for almost a week now and noone's been able to shed
          any light on it. My evaluation of the product is about to end and, as things currently
          stand, I've concluded that "it doesn't work"! Surely that's not right?!
          I'm getting a ClassNotFoundException when I try to store one of my classes in
          the session.
          If I have session state replication disabled then I don't get it. As soon as I
          enable replication it gets thrown. Clearly 6.1b is unable to replicate my object
          to the secondary server. Session persistence and failover is working fine with
          Strings, ArrayLists etc. It doesn't want to know about my Serializable class,
          though!
          The class is definitely on both servers since I've deployed the web application
          from the admin server and can successfully run the application on both servers
          in the cluster. It's just the persistence mechanism that is unable to find the
          class!
          Anyone got any ideas as to what I'm doing wrong?
          I'm not too keen on having to replace 6.1b with 6.0sp2 since 6.1b was recommended
          by BEA support for our evaluation and it would undo a week's work.
          Thanks,
          K.


Which machine gets the error, the primary where you are doing the
          session.putValue() or does it appear on the replicated server?
          I assume your class is Serializable..
          Is the class in question in the Java classpath, or just in the web app? Try
          placing the class in the java classpath during boot on both sides, see if
          that helps.
          A full error stack would be helpful..
          -Greg
          "KPSeal" <[email protected]> wrote in message
          news:[email protected]...
          >
          > Help! This has been bugging me for almost a week now and noone's been able
          to shed
          > any light on it. My evaluation of the product is about to end and, as
          things currently
          > stand, I've concluded that "it doesn't work"! Surely that's not right?!
          >
          > I'm getting a ClassNotFoundException when I try to store one of my classes
          in
          > the session.
          > If I have session state replication disabled then I don't get it. As soon
          as I
          > enable replication it gets thrown. Clearly 6.1b is unable to replicate my
          object
          > to the secondary server. Session persistence and failover is working fine
          with
          > Strings, ArrayLists etc. It doesn't want to know about my Serializable
          class,
          > though!
          > The class is definitely on both servers since I've deployed the web
          application
          > from the admin server and can successfully run the application on both
          servers
          > in the cluster. It's just the persistence mechanism that is unable to find
          the
          > class!
          >
          > Anyone got any ideas as to what I'm doing wrong?
          >
          > I'm not too keen on having to replace 6.1b with 6.0sp2 since 6.1b was
          recommended
          > by BEA support for our evaluation and it would undo a week's work.
          >
          > Thanks,
          > K.

Clustering/Session Replication

Hi,
I know that's a fairly basic question, but I just want to make sure I am not missing anything here.
We have an application which runs on a cluster of WebLogics and the user sometimes is requested to sign in again (it seems like it hit another instance and the session is not there).
The admins from Weblogic say there is NO WAY to disable Session Replication when running Weblogic in a cluster, which makes total sense. They say, however, that if the application doesn't serialize its session, then Weblogic can't handle the serialization. In short, they say it's an application issue.
The developers say the application is written properly, and that the problem is in Weblogic's side.
Although I am still a developer (for my own projects), my role here doesn't allow me to look into the code, how can I show the developers that WebLogic is setup correctly and that they need to fix their code?
Regards

Information about session replication can be found here: http://docs.oracle.com/cd/E21764_01/web.1111/e13709/failover.htm#i1024620
it contains a section 'Requirements for HTTP Session State Replication' that might be helpful to you.
Also important to note is, how the load balancer handles session binding and the WebLogic cookie
http://docs.oracle.com/cd/E21764_01/web.1111/e13709/load_balancing.htm#i1026939

Proxyless clustering and SSL session state

The current 6.0 docs are a bit quiet on SSL and clustering, so can I check
          whether it is the case that when proxy-less clustering is used with SSL, a
          failover results in a new certificate exchange and crypto session
          establishment? In other words, the clustering isn't attempting to replicate
          the SSL session state or similar super-subtle strategy.
          Thanks!
          Alex Thomas
          Lehman Brothers
          London


          "Alex Thomas" <[email protected]> wrote in message
          news:[email protected]..
          > The current 6.0 docs are a bit quiet on SSL and clustering, so can I check
          > whether it is the case that when proxy-less clustering is used with SSL, a
          > failover results in a new certificate exchange and crypto session
          > establishment? In other words, the clustering isn't attempting to
          replicate
          > the SSL session state or similar super-subtle strategy.
          Alex,
          A failover will result in a new SSL connection being started. As you say
          this will mean that certificate exchange and session key exchange will occur
          again. All of the replicated state is kept at a higher level in the server
          so that we can use different SSL implementations including hardware
          accelerators.
          Regards,
          Adam

Problem in accessing JSP in a Clustered Session replicated environment

          Hai All!
          When i tried to access Index.jsp in a clustered-Session inmemmory replicated environment
          it is throwing following exception,,
          What Might be the reason..
          <Aug 1, 2001 12:11:19 PM GMT+05:30> <Error> <HTTP> <[WebAppServletContext(6493555,DefaultWebApp_ClusterServerA)]
          Servlet failed with Exception java.lang.ClassCastException: weblogic.servlet.internal.session.MemorySessionContext
          at weblogic.rmi.internal.AbstractOutboundRequest.sendReceive(AbstractOutboundRequest.java:90)
          at weblogic.cluster.replication.ReplicationManager_WLStub.create(ReplicationManager_WLStub.java:192)
          at weblogic.cluster.replication.ReplicationManager.trySecondary(ReplicationManager.java:587)
          at weblogic.cluster.replication.ReplicationManager.createSecondary(ReplicationManager.java:565)
          at weblogic.cluster.replication.ReplicationManager.register(ReplicationManager.java:344)
          at weblogic.servlet.internal.session.ReplicatedSessionData.<init>(ReplicatedSessionData.java:128)
          at weblogic.servlet.internal.session.ReplicatedSessionContext.getNewSession(ReplicatedSessionContext.java:123)
          at weblogic.servlet.internal.session.SessionContext.getNewSessionInstance(SessionContext.java:121)
          at weblogic.servlet.internal.ServletRequestImpl.getNewSession(ServletRequestImpl.java:1552)
          at weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.java:1415)
          at jsp_servlet._index._jspService(_index.java:80) at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
          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)
          > <Aug 1, 2001 12:12:37 PM GMT+05:30> <Error> <HTTP> <[WebAppServletContext(6493555,DefaultWebApp_ClusterServerA)]
          Servlet failed with Exception java.lang.ClassCastException: weblogic.servlet.internal.session.MemorySessionContext
          at weblogic.rmi.internal.AbstractOutboundRequest.sendReceive(AbstractOutboundRequest.java:90)
          at weblogic.cluster.replication.ReplicationManager_WLStub.create(ReplicationManager_WLStub.java:192)
          at weblogic.cluster.replication.ReplicationManager.trySecondary(ReplicationManager.java:587)
          at weblogic.cluster.replication.ReplicationManager.createSecondary(ReplicationManager.java:565)
          at weblogic.cluster.replication.ReplicationManager.register(ReplicationManager.java:344)
          at weblogic.servlet.internal.session.ReplicatedSessionData.<init>(ReplicatedSessionData.java:128)
          at weblogic.servlet.internal.session.ReplicatedSessionContext.getNewSession(ReplicatedSessionContext.java:123)
          at weblogic.servlet.internal.session.SessionContext.getNewSessionInstance(SessionContext.java:121)
          at weblogic.servlet.internal.ServletRequestImpl.getNewSession(ServletRequestImpl.java:1552)
          at weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.java:1415)
          at jsp_servlet._index._jspService(_index.java:80) at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
          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)
          >
          Can anybody suggest what went wrong?
          TIA Rgds Manohar


[att1.html]

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

First Hit Session Data Replication

We are using WLS 5.1 with sp3 in a cluster of three
          servers using in-memory-rep, JSP, and Apache as our proxy.
          Session data replication between a primary and secondary server
          seems to work fine except in the following case:
          1) Make first hit to the cluster. During the JSP processing of
          that hit set some HTTP session data via setAttribute().
          2) Kill-off the primary server (the one that handled the first hit).
          3)Make a second hit to the cluster, it is handled by another
          server (the secondary), the session is recognized as an ongoing
          session however the session data that was set during the first hit is not
          present in the second hit.
          If we make two hits to the first server and set data, then kill-off
          the primary server, the secondary has the data at the third hit. The
          only issue seems to be when the primary is killed after the first hit.
          Anyone have any ideas?
          Thanks,
          -darren


You can configure ClusterServlet in your web server farm (WLAS as web
          servers) to proxy JSP and servlet requests to the WLAS farm (WLAS processing
          your JSP and servlet).
          Set up in-memory replication in your WLAS farm. Session in JSP will be
          replicated.
          Cheers - Wei
          Yen Liu <[email protected]> wrote in message
          news:[email protected]...
          > Hello,
          >
          > I read breifly the section on BEA's online documentation talking about
          in-memory
          > replication and clustering.
          >
          > In it, it mentioned the ClusterServlet and configuring the
          weblogic.properties
          > file to assign servlets to the ClusterServlet so that sessions will be
          handled
          > correctly and all.
          >
          > My question is, "what about JSP" I am using a lot of JSP pages which sets
          > session parameters for the specific user into session objects.
          >
          > Any tips, recommendations will be most helpful.
          >
          > Thanks,
          >
          > Yen Liu
          > 510/870-1169
          >
          > Prasad Peddada wrote:
          >
          > > Darren,
          > >
          > > It shouldn't be the case. After your first hit, when you kill the
          primary
          > > server, when you make your next request you should find all the info in
          the
          > > session. I will post again, if we find the same problem on monday in our
          test
          > > environment.
          > >
          > > Thanks
          > >
          > > Prasad
          > >
          > > Darren Kessler wrote:
          > >
          > > > We are using WLS 5.1 with sp3 in a cluster of three
          > > > servers using in-memory-rep, JSP, and Apache as our proxy.
          > > > Session data replication between a primary and secondary server
          > > > seems to work fine except in the following case:
          > > >
          > > > 1) Make first hit to the cluster. During the JSP processing of
          > > > that hit set some HTTP session data via setAttribute().
          > > > 2) Kill-off the primary server (the one that handled the first hit).
          > > > 3)Make a second hit to the cluster, it is handled by another
          > > > server (the secondary), the session is recognized as an ongoing
          > > > session however the session data that was set during the first hit is
          not
          > > > present in the second hit.
          > > >
          > > > If we make two hits to the first server and set data, then kill-off
          > > > the primary server, the secondary has the data at the third hit. The
          > > > only issue seems to be when the primary is killed after the first hit.
          > > >
          > > > Anyone have any ideas?
          > > >
          > > > Thanks,
          > > >
          > > > -darren
          >

State Replication option..

Is there some way of specifying whether the state replication should happen synchronously or asynchronously.
          Also, is there some way that the state replication decision can be made custom driven. By this i mean user writing the code which decides whether the state has changed and needs to be communicated. This could be useful in a Stateful session bean where one might like to decide when to replicate (i.e. on change of which all atrributes should the replication occur).
          JBoss has a mechanism by which we can specify a mehtod isModified which should return boolean, which is called before replicating the state. THis helps in achieving fine-grained replcation.

For stateful sessoin EJBs the container automatically determines whether you've modified anything and sends the minimal diff across the wire. There's no need to write an isModified method (which I would consider a little error-prone and cumbersome).
          The replication is always done synchronously. There is no option currently to make it async but other people have asked for it.
          -- Rob
          WLS Blog http://dev2dev.bea.com/blog/rwoollen/

How to tell if a user is issuing 'alter session statements'

When I run 'alter session' from sqlplus in my schema, this does not get parsed and go to v$sql or show up in v$open_cursor. I have a user that is running queries from informatica. He says he is passing alter session statements through informatica, I want to see if they actually get there. The person is not real versed in oracle and I don't know informatica.
i cant turn on trace cause he connects and disconnects and this would run immediately, I am not in a position to turn on system level tracing, add a trigger, or turn on auditing (not allowed).
anyway to tell from a data dictionary view or something like that if these were issued by a given session? The queries run for a few minutes, so I have a bit before his session disconnects to query the data. I can't get him to change his code to stay connected. Is there a view that shows parameter changes for a given session?
oracle: 10.2.0.5
4 alter session commands are:
Alter session set sort_area_size=999999999;
Alter session set hash_area_size=999999999;
Alter session set db_file_multiblock_read_count = 128;
alter session enable parallel dml;
Edited by: Guess2 on Jul 17, 2012 12:49 PM

i cant turn on trace cause he connects and disconnects and this would run immediately, I am not in a position to turn on system level tracing, add a trigger, or turn on auditing (not allowed). If Informatica connects to Oracle via network, capturing TCP/IP traffic and mining in it may be your last resort.
you can get session's PDML status from
select pdml_status from v$session;
i cant turn on trace cause he connects and disconnects and this would run immediatelythis contradicts to your following statement
The queries run for a few minutes, so I have a bit before his session disconnects to query the data.
I can't get him to change his code to stay connected. Informatica should have debug. Ask him if he can go step by step.
Edited by: user11181920 on Jul 17, 2012 5:53 PM

Session state is not being passed properly to another page

Hello Gurus,
I have a multi-page application which authenticates using a simple authentication page 101. Right now I have a generic authentication scheme which always returns true (Session Verify Function= return true; I will integrate LDAP later.) It works fine. The app remembers the username from one page to the next (popup pages mainly).
My issue is that, after exporting the application and re-importing into a new workspace, the user/session state is no longer being preserved from page to page. It prompts for a login every new page that is opened (the popups). This ruins the flow and functionality of the app.
I've checked every setting (I think) and cannot find any differences between the two workspaces or apps. Any ideas why this would work in one workspace and not the other?
TIA!
Jonathan
I should also indicate that the issue seems to be specifically in calling "callmypopup" function. For some reason it isn't passing the session id properly to the popup page, where it did fine in the other workspace. function text:
function callMyPopup (sourceItem, popuppagenum, targetItem, appid, appsession) {
//opens popup pg and passes value in sourceItem to targetItem
//sourceitem=calling text box, targetItem=text box in popup page
var minlength = 3;
if (CheckLength(sourceItem, minlength))
var formVal1 = document.getElementById(sourceItem).value.toUpperCase();
var url;
url = 'f?p=' + appid + ':' + popuppagenum + ':' + appsession + '::::' + targetItem + ':' + formVal1;
w = open(url,"winLov","Scrollbars=1,resizable=1,width=800,height=600");
if (w.opener == null)
w.opener = self;
w.focus();
else {alert('Please enter at least ' + minlength + ' characters in your search.');}
Edited by: austindurant on Sep 5, 2008 7:02 AM
Edited by: austindurant on Sep 5, 2008 7:46 AM

It looks like your session id is not correctly passed to your popup page. Try using:
javascript:popUp2('f?p=&APP_ID.:1:&SESSION.:::::', 600, 700);
instead, which does the same thing. Put your parameters for the page items there if required.
Denes Kubicek
http://deneskubicek.blogspot.com/
http://www.opal-consulting.de/training
http://apex.oracle.com/pls/otn/f?p=31517:1
-------------------------------------------------------------------

Problem with application item and session state

Okay, let's see if I can explain this problem coherently.
I have a small app (one page), with an application item, F_WHERE_CLAUSE.
This page has three regions in which there are items that the users can populate for search conditions. A couple of these items are "select list with submit" (I still need to upgrade to the AJAX method, I know). There is another region which has one hidden field, called P1_WHERE_CLAUSE. This field is defined to "Always, replacing any value in session state..." with source type of "Item (application or page.....", and a source value of F_WHERE_CLAUSE with no default value.
I have a button called "Search" which submits the page and fires a PL/SQL process which builds a where condition based upon the other page items and stores the value to the application item F_WHERE_CLAUSE (correctly).
For testing, I've made the P1_WHERE_CLAUSE field visible so that I can see what's going on. I've also clicked the debug and session buttons to help trace this. After I click the "Search" button and the page submits, debug shows:
0.02: ...Session State: Save "P1_WHERE_CLAUSE" - saving same value: "1=1"
followed later by:
0.05: ...Session State: Saved Item "F_WHERE_CLAUSE" New Value="lower(primary_class) = 'rock' and country = 'Spain'"
The field P1_WHERE_CLAUSE displays with the correct search criteria as signified by F_WHERE_CLAUSE above. However, If I click the "session" button to view the session state values, P1_WHERE_CLAUSE shows up as:
P1_WHERE_CLAUSE Textarea 1=1 U while F_WHERE_CLAUSE displays the correct value still.
The reason this "problem" came up, is that this page also has three SQL report regions which use &P1_WHERE_CLAUSE. for the where condition. While they display the correct results on-screen, each report region also has the "Export to csv" enabled, and the export seems to be using the "1=1" condition (from the "session" window) instead of the search criteria that the on-screen region is using (F_WHERE_CLAUSE and the displayed P1_WHERE_CLAUSE), resulting in a retreival of all records.
Anybody have any idea what's going on and why, and how to get the csv export to use the correct value for the where condition?
Thanks,
Bill Ferguson

It appears the "Export to CSV" functionality requires the item value to be set in session state. The P1_WHERE_CLAUSE item value never gets saved to session state. The page is rendered and the value is put in the item on the page but until you submit the page session state doesn't know what P1_WHERE_CLAUSE is.
Create a before header computation or process to set the value of P1_WHERE_CLAUSE (which will save it to session state). It is interesting that the report regions didn't need to look at the value in session state but the "export to csv" does.
--Jeff

Clustered session state replication

Similar Messages

Maybe you are looking for