Session handling and failover

[dagfinn]

This is another comment to HarryF's original post in Are PHP apps fundamentally data driven?. It's another argument against his hypothesis and the more general notion that PHP's inability to store session data in memory has major architectural implications.

I was recently asked the question: how do you do failover with PHP? I had to admit I'd never heard of the concept, but it's not a difficult one. It means having the ability to switch the user transparently between different Web servers so that if one server fails, the user won't notice anything.

The person who asked me explained that the J2EE programmers had told him J2EE would handle this for them. I said, in PHP you could store the session in a database.

I just realized that this has some bearing on the question of how different PHP is from other platforms. For failover, you presumably need to be prepared for the possibility that a server is blown away in an instant as a result of massive hardware failure. That means there will be no way to salvage data from RAM on that machine. So the session must be stored somewhere else, most likely on disk.

In other words, any application that requires failover cannot simply store session data in memory. Regardless of programming language or platform, it has to use some other strategy, and almost certainly one that can be duplicated in PHP.

Am I right, or did I miss something important?

[Widow Maker]

Can see what your asking, but not where your going with it.

Are you asking if it's better to put your sessions in a database, over PHPs default file ?

If so, then yes This also offers a few more advantages. If this isn't your question, can you explain a bit more ?

[Azmo]

There seem to be three options: cookies, PHP sessions, and DB sessions. Why not use all three at the same time? It should be possible to build an acceptable failover system that way.

[DaveCheney]

failover or clustering needs you to store data in a way that all the severs in your cluster can access. So for sessions that means in a database or in shared file storeage (if you think nfs, etc can handle the locking properly) - the defacto is to create a custom db based session handler.

As for other 'data' there is state that your application could have,say if you are part way through posting to a forum, that data could be in a session or maybe on the request line but you should always structure your application in such a way that at any point, any server can handle the request without having any special knowledge of the state (other than what is available in the sesion or request line)

[dagfinn]

Can see what your asking, but not where your going with it.

I can see that that's difficult. I'm not asking a technical question; I'm trying to discuss the implications of PHP's session handling.

Let me try to state my point more simply: HarryF hypothesizes that PHP apps are "data driven" because sessions can't be stored in memory. I say that if so, all applications that implement failover would be "data driven" as well.

[Selkirk]

Interesting. I wonder if "statefull" java apps trying to implement failover just end up doing all the same work that "stateless" PHP does?

[dagfinn]

Interesting. I wonder if "statefull" java apps trying to implement failover just end up doing all the same work that "stateless" PHP does?

It seems that J2EE does it for you transparently, and it's "elementary, my dear Watson" that it most likely does so by storing the session serialized in a database. And, of course, you can do the same thing in PHP.

I think the concepts of "stateful" and "stateless" are too simplistic to be very useful. HTTP is commonly called stateless, and it's true that it doesn't require, define or imply that state be kept on the server. But even simple hypertext implies that the interaction between the client and the server has a state between requests. That state is represented by the current document, which is fully defined by a URL.

Session handling typically means storing some of the application's state on the server. (Although it can be in cookies on the client as well.) Whether it's in memory or on disk is only a performance issue as far as I can tell. And if the time it takes to get and unserialize the session is small compared to the total time the application takes to run, I don't see why it should be so important. As you said in the other thread, today's overhead is tomorrow's who cares.

[lastcraft]

Hi...

...it's "elementary, my dear Watson" that it most likely does so by storing the session serialized in a database.

What if you used a USB key? In fact an external shared memory source using a disk protocol, such as firewire, would seem sensible. Hey, If you add failover, you could call it RAM RAID !

yours, Marcus