Jacky,
 
Whatever you quoted (in red) does not apply to your case, because in most of 
your situations, you did not have another Resin instance to be notified, as in 
"it will notify the owner of the change...."     At some point of step 2 and 
step 5, you did not even have any Resin instance running.
 
But that does not mean this is not a problem. JDBC based session store should 
always contain the last known valid state, no matter which server was running.  
I noticed that your case has been filed into Resin bug 
http://bugs.caucho.com/view.php?id=1544 
<http://bugs.caucho.com/view.php?id=1544.> .
 
So, stop worrying.
 
 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jacky
Sent: Monday, January 15, 2007 2:17 AM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Question on db based distributed session


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