Eric? Sam?
Warm regards,
Jacky Wong
Software Engineer
Qinetics Solution Berhad


Jacky wrote:
Dear all,

First of all, thanks for all the attentions. Greatly appreciated.

Josh,
- Please forgive me as i do not understand your "have your cake and eat it too" metaphor :S
- I'm trying to implement the database backed distributed sessions as shown in http://www.caucho.com/resin-3.0/config/sessions.xtp and i dont take "turn it off" as a solution, at least not until i fully understand that this will not work.
- You may be right with the clock of server A and server B not in sync, I'll have it checked..

Eric,

- Yes, resin knows about my load balanced cluster (refer to the specific settings below)
- I'm using apache with mod_caucho as the load balancer, is this inside or outside? :D
- No, i'm not using <always-load-session>. I didnt' think that i need (but i'll give it a shot). Referring to http://www.caucho.com/resin-3.0/config/sessions.xtp, there is a paragraph stating this:

"For efficiency, the owning JVM keeps a cache of the session value, so it only needs to query the database when the session changes. If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware."

my specific settings:

#Apache snippet
<VirtualHost *:80>
  DocumentRoot /www/appA
  ServerName somedomain.com
  DirectoryIndex index.jsp
  ResinConfigServer 192.168.1.1 6802
  ResinConfigServer 192.168.1.2 6802
  CauchoStatus yes

  # do not remove, otherwise apache will serve the jsp source code once resin is down
  AddHandler caucho-request .jsp
</VirtualHost>

# Resin snippet
    <!-- Yes i'm aware that client-live-time and read-timeout is not supposed to be manually configured -->
    <cluster>
      <client-live-time>120s</client-live-time>
      <srun id="a" host="192.168.1.1" port="6802" index="1" read-timeout="120s"/>
      <srun id="b" host="192.168.1.2" port="6802" index="2" read-timeout="120s"/>
    </cluster>

      <persistent-store type="jdbc">
        <init>
          <data-source>jdbc/session</data-source>
        </init>
      </persistent-store>

    <host id="somedomain.com" root-directory="/www/appA">
      <web-app id="/" document-directory="/www/appA">
        <session-config>
          <!-- 3 hour timeout -->
          <session-timeout>180</session-timeout>
          <use-persistent-store/>
          <always-save-session/>
        </session-config>
        <servlet-mapping url-pattern="/servlet/*" servlet-name="invoker"/>
      </web-app>
    </host>

Sam,

I have 2 questions:

Quote:

At this point, A (the primary) will contact B to try to get any updates
to the session that have been made.  Since B is down, A cannot get the
session from it. 

- Since i use <always-save-session>, shouldn't it try to get from B, but couldn't it get from the DB?

Quote:

So it has to go with the outdated session that it
has, because it cannot get the updated session from B.

- Please do correct me if i'm wrong, referring to this:

"If another JVM stores a new session value, it will notify the owner of the change so
the owner can update its cache.  Because of this notification, the database
store is cluster-aware."

- When B logs out my session, shouldn't it updates A's cache and the database at the same time?
- Is it because i didn't use <always-load-session> ??

Gary Zhu,

Quote:
Even if server A and server B are configured to use the same database on server C, for a particular user session (say session id: abcDGs299928), server A and server B will have two different database entries of the session data, am I getting it right ?

- I have thought of this as well when i look at the records in the table persistent_session of my mysql database.
- But still...

"If another JVM stores a new session value, it will notify the owner of the change so
the owner can update its cache.  Because of this notification, the database
store is cluster-aware."

PS:
Apache/2.0.55
Resin professional 3.0.19.

Thanks all !!
  
Warm regards,
Jacky Wong
Software Engineer
Qinetics Solution Berhad
  


Sam wrote:
1. I start server A and login to my application
      

At this point, A will get your request and will become your primary
server, and B will be your secondary server.

  
2. I stop Server A and start Server B
3. I continue to work in the browser, my session stays intact and i 
can proceed normally
      

At this point, you are using secondary server B.  Your session updates
are saved on B.

  
4. I logout from my application and logout successfully cleared my 
session variables (notice this from app log)
5. I stop Server B and start Server A
      

  
6. I try to type a password protected page in the browser and i *CAN 
ACCESS* the protected page
      

At this point, A (the primary) will contact B to try to get any updates
to the session that have been made.  Since B is down, A cannot get the
session from it.  So it has to go with the outdated session that it
has, because it cannot get the updated session from B.

-- Sam

_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

  

_______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to