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

Reply via email to