Women in Technology

Hear us Roar

  The PHP Scalability Myth
Subject:   Hidden variables for session state?
Date:   2003-10-17 12:32:11
From:   anonymous2
Response to: Hidden variables for session state?

How about a known set of responses for, say, a price? Any non-combo-box sort of data? A credit card? There's plenty of data where it's not so easy to know what's valid and what's not. Just because there are say, four known responses, it doesn't mean that any of the four are really appropriate for the current user. As far as POST vs. GET...I can submit anything I want (with any claimed User-Agent) that I want via POST with HTTPUnit.

Not to mention the overhead of taking a complex set of data, serializing it to something that is acceptable to HTTP forms, and then deserializing it back to object-land when the request is submitted. If you're a simple online store, sure, PHP and the bad patterns you suggest will suffice. Write a very complicated enterprise app that has to support tens of thousands of concurrent users with failover with PHP and then come back. You can unplug the LAN cable from a server mid-request and WebLogic will fail over without a hitch. Stick that in your crack pipe and smoke it.

Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • Hidden variables for session state?
    2003-10-17 15:17:31  anonymous2 [View]

    The problem with your position (IMHO) is I've already done the things you suggest...hundreds of thousands of lines of code....maintained by disparate developers on different continents, some of whom DO NOT speak the same language....using OO to provide classes, methods, etc.....blah, blah, blah....using both coding environments (Java and PHP).

    The unplugging the cable thing is easily solved by using a DB to store one's session info and *NOT* a memory resident process to keep track of uniquely identified users. You see, in the world of system design simplest wins and most complex looses. Store info in EJBs in memory....sure, why not...of course if the WebLogic/JBoss/other Java engine hiccups or because of latency fails to replicate session(s) to peers....viola, lost sessions and pissed users. In the DB scenario the session persists happily and the user never knows if ONE OR MORE of the cluster members went down because there's NO NEED FOR SAID USER TO CARE. On the issue of WebLogic failing over without a hitch, not so fast. I've seen it fail to do just that MANY times from Ver 6.x through current releases.

    On the "bad patters I suggest"....I wasn't suggesting anything. I was simply mentioning how one might reduce the complexity of their design by thinking in simple terms. Again, simple wins, complex looses. Item prices for goods and services should ALWAYS be know to the selling business unit that's selling said thing. If not, the Java vs. PHP thing is a non issue because said business won't be around for long.

    As for your "Just because there are say, four known responses, it doesn't mean that any of the four are really appropriate for the current user."...you're right. However, if one follows a well designed set of business rules/business processes based on the technically engineered process at hand then the problems with erroneous data making it to the DB is MUCHO reduced (think good design here).

    So you see, proper design + proper tool + simplest implementation/design = success. Do I think Java offers this? Sure, but only in a situation where something in Java is required (make sure it's required or it's only added complexity). Is PHP always the correct choice? No, but then again when one builds a house the saw is not always the correct tool.