Re: [Resin-interest] Question on db based distributed session

[Jacky]

Gary, thanks for the reply.
Warm regards,
Jacky Wong
Software Engineer
Qinetics Solution Berhad



Gary Zhu wrote:

  
  
  
  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.
   
  So, stop worrying.
   
   
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On 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 . 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

  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

  
# Resin snippet
    
    
  120s
  
  
    
  
  
    
  jdbc/session
    
  
  
    
  
    
  
  180
  
  
    
    
  
    
  
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 , 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  ??

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 intac

Re: [Resin-interest] Question on db based distributed session

[Gary Zhu]

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

  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


# Resin snippet


  120s
  
  


  

  jdbc/session

  


  

  
  180
  
  


  


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



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 s

Re: [Resin-interest] Question on db based distributed session

[Jacky]

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

  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

  
# Resin snippet
    
    
  120s
  
  
    
  
  
    
  jdbc/session
    
  
  
    
  
    
  
  180
  
  
    
    
  
    
  
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 , 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  ??

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

Re: [Resin-interest] Question on db based distributed session

[Jacky]

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

  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


# Resin snippet
    
    
  120s
  
  
    

  
    
  jdbc/session
    
  

    
  
    
  
  180
  
  
    
    
  
    

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

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

Re: [Resin-interest] Question on db based distributed session

[Gary Zhu]

Thank you Sam, for the explanation.

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 ?


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Sam
> Sent: Monday, January 08, 2007 1:17 PM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Question on db based distributed session
> 
> 
> > >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

Re: [Resin-interest] Question on db based distributed session

[Sam]

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

Re: [Resin-interest] Question on db based distributed session

[Josh Rehman]

Hmm. I was reading:

  http://www.caucho.com/resin-3.1/doc/tcp-sessions.xtp

Particularly the section under "recovery" which states:

"When Host C restarts, possibly with an upgraded version of Resin, it
needs to use the most up-to-date version of the session; its
file-saved session will probably be obsolete. When a "new" session
arrives, Host C loads the saved session from both the file and from
Host D. It will use the newest session as the current value. Once it's
loaded the "new" session, it will remain consistent as if the server
had never stopped."

So Resin actually implements "have your cake and eat it too" but it's
not working in your case. Perhaps there is some error when the
comparison is made - perhaps the clocks on the two systems are not in
sync. Or something. :)

Peace,
Josh

On 1/8/07, Josh Rehman <[EMAIL PROTECTED]> wrote:
> Corrections below:
>
> On 1/8/07, Josh Rehman <[EMAIL PROTECTED]> wrote:
> ...
> > While there are [[hacky]] ways to notify the "offline" server of state 
> > changes
> ...
> > How can you have your cake and eat it too? You need some way for nodes
> > to see if they are participating in a distributed session [[on startup]] 
> > and if they
> > are and if there is an active node, ignore any persisted session state
> > and get state from the distributed session. If there is no active
> > node, then load session from disk.
> ...
>
> Peace,
> Josh
>

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

Re: [Resin-interest] Question on db based distributed session

[Eric Kreiser]

what are your specific session settings?  does resin know about your 
load balanced cluster? or are you managing the load balancer outside of 
resin and using resin to tie them together thru the db persistence?  are 
you using 'always-load-session"?




Jacky wrote:

Dear all,

I have implemented resin's distributed session along with apache. 
Apache is the entry point, which will use mod_caucho plugin to 
dispatch requests to resin.

Now it is working fine and i'm happy about it.

After a few test run on this, i found out something which i'm not sure 
if its my implementation problem or bug.

I have server A and server B running resin on default srun port 6802.

Unhappy case 1:
1. I start server A and login to my application
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

4. I stop Server B and start Server A
5. I continue to work in the browser, my session stays intact and i 
can proceed normally
6. I logout from my application and logout successfully cleared my 
session variables (notice this from app log)
7. I try to type a password protected page in the browser and i am 
forced to login

8. I stop Server A and start Server B
9. I try to type a password protected page in the browser and i *CAN 
ACCESS* the protected page


Unhappy case 2:
1. I start server A and login to my application
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
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


So to sum it all up, if i login to Server A and try to log out in 
Server B, the session is still available to server A and not Server B.

Does anyone here encounter this before?

Thanks.
--
Warm regards,
Jacky Wong

  


--
This message has been scanned for viruses and
dangerous content by *MailScanner* , and is
believed to be clean.


___
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

Re: [Resin-interest] Question on db based distributed session

[Josh Rehman]

Corrections below:

On 1/8/07, Josh Rehman <[EMAIL PROTECTED]> wrote:
...
> While there are [[hacky]] ways to notify the "offline" server of state changes
...
> How can you have your cake and eat it too? You need some way for nodes
> to see if they are participating in a distributed session [[on startup]] and 
> if they
> are and if there is an active node, ignore any persisted session state
> and get state from the distributed session. If there is no active
> node, then load session from disk.
...

Peace,
Josh

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

Re: [Resin-interest] Question on db based distributed session

[Josh Rehman]

Hi Jacky,

Please forgive my comment - I don't use distributed sessions, but I
think that you are running into a theoretical limitation of the
feature: offline servers participating in a cluster cannot, in
general, be notified of changes to session state of online servers.

This fact could cause some much more subtle bugs, in analogy to
so-called "update anomalies" in a denormalized database. If requests
are coming through in a load-balancer, those requests might very well
be coming in with subtly different context, creating all kinds of
strangeness.

While there are ways to notify the "offline" server of state changes
(via disk or database) I would guess that the central problem is that
the offline server is serializing session state on shutdown, and then
reading that state on startup, creating the inconsistency. (I wonder
though if when that session data is read whether it overrides the
session state on the already-running machine?)

You could see if this is the problem by turning off session
persistence on both servers and repeat your tests.

How can you have your cake and eat it too? You need some way for nodes
to see if they are participating in a distributed session and if they
are and if there is an active node, ignore any persisted session state
and get state from the distributed session. If there is no active
node, then load session from disk.

I would argue that just turning off session persistence is the best
thing to do. If the last box in your cluster goes down, you probably
have bigger things to worry about than user session data.

Peace,
Josh

On 1/8/07, Jacky <[EMAIL PROTECTED]> wrote:
>
>  Dear all,
>
>  I have implemented resin's distributed session along with apache. Apache is
> the entry point, which will use mod_caucho plugin to dispatch requests to
> resin.
>  Now it is working fine and i'm happy about it.
>
>  After a few test run on this, i found out something which i'm not sure if
> its my implementation problem or bug.
>  I have server A and server B running resin on default srun port 6802.
>
>  Unhappy case 1:
>  1. I start server A and login to my application
>  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
>  4. I stop Server B and start Server A
>  5. I continue to work in the browser, my session stays intact and i can
> proceed normally
>  6. I logout from my application and logout successfully cleared my session
> variables (notice this from app log)
>  7. I try to type a password protected page in the browser and i am forced
> to login
>  8. I stop Server A and start Server B
>  9. I try to type a password protected page in the browser and i CAN ACCESS
> the protected page
>
>  Unhappy case 2:
>  1. I start server A and login to my application
>  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
>  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
>
>  So to sum it all up, if i login to Server A and try to log out in Server B,
> the session is still available to server A and not Server B.
>  Does anyone here encounter this before?
>
>  Thanks.
>  --
> Warm regards,
> Jacky Wong
>
>
>
> ___
> 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] Question on db based distributed session

[Jacky]

Dear all,

I have implemented resin's distributed session along with apache.
Apache is the entry point, which will use mod_caucho plugin to dispatch
requests to resin.
Now it is working fine and i'm happy about it. 

After a few test run on this, i found out something which i'm not sure
if its my implementation problem or bug.
I have server A and server B running resin on default srun port 6802.

Unhappy case 1:
1. I start server A and login to my application
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
4. I stop Server B and start Server A
5. I continue to work in the browser, my session stays intact and i can
proceed normally
6. I logout from my application and logout successfully
cleared my session variables (notice this from app log)
7. I try to type a password protected page in the browser and i
am forced to login
8. I stop Server A and start Server B
9. I try to type a password protected page in the
browser and i CAN ACCESS the protected page

Unhappy case 2:
1. I start server A and login to my application
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
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

So to sum it all up, if i login to Server A and try to log out
in Server B, the session is still available to server A and not Server
B.
Does anyone here encounter this before?

Thanks.
-- 
Warm regards,
Jacky Wong





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