On Wed, 2005-12-14 at 21:34, Christopher Jordan wrote: > Rob, > > Thanks for responding. :) I have more questions. I hope that's okay. :)
*lol* No problem :) > > You said: > "Share nothing" refers to the PHP philosophy of not tying any data > sharing system to the engine itself. > In this way developers are free to create applications in such a way that if > they need more power, they can just add more computers. > ----- > I guess I'm a little confused, by this and by what Jochem originally posted. > I'm not sharing data between different computers within the application (if > that makes sense). In other words, of course all my data (in this case > inventory data) is in a MySQL table, and so multiple users could be accessing > the data simultaneously. The session variable only serves to store (for > display purposes, really) the results of the users last search. I also > maintain a $_SESSION["LoggedIn"] variable to keep track of whether the user > has access in this session. Sorry, I was merely responding to your question about what "share nothing" meant. With respect to how this relates to you, your sessions and what Jochem wrote... If I read your above comment correctly it doesn't really sound like it applies to your problem only that you used ColdFusion to describe what you would have done in that environment. Sessions by nature are per user only and not application scoped. > > You said: > This becomes a much more difficult issue when a program holds private data in > memory that requires a specific way to access it. For instance if you stored > some kind of application variable in memory (a la ColdFusion, Java, ASP) then > this value would not be normally transparent to other computers without some > kind of synchronization system to transfer it around. > ---- > Perhaps I'm being dense (it wouldn't be the first time), or maybe a bit > unimaginative, but I can't think of an instance where while a user is logged > into an app and using it, that another computer (besides the web server, > database server and the client machine), would need to have access to that > data. > Are you referring to "state" here? Or.... well other than passing data around > between browser windows, I'm not really sure what you mean. I'd love it if > you could find the time to expand on that. Imagine a configuration system loaded from a slow medium and cached in the running process for all subsequent page requests. The speed advantage is immense, but it violates the "share nothing" rule. To emulate this in PHP one would punt the cached data to a database so that it could be retrieved in a single lightweight query. In this respect PHP often differs from Java or ASP that often load configuration data and keep it resident for some time. That said, PHP merely forces the user into the share nothing philosophy, whereas Java lets the developer choose since anyone can write their code to share nothing if they want. In this regard-- protect the users from shooting themselves in the foot-- PHP often takes an arguably overzealous position. > You Said: > Using the share nothing philosophy such data doesn't generally exist, and if > it does, then it is stored in a database. Databases are a better system for > such data since they were designed for heterogeneous external access and > quite handily solve the race condition and deadlock issues. > --- > Typically I think of the session variable scope as a way to preserve state. > Are you suggesting that state be preserved by dumping information down to and > then reading it again from a database? For example my session variable which > indicates the user has successfully logged in... Nope you are right, I think perhaps Jochem unintentionally confused the issue by bringing up the "share nothing" philosophy. I merely spoke to that when I described it. > In speaking of *large* scale applications I suppose I might be able to see > where you'd want something different than the session superglobal since the > more users you have accessing the app and using that scope, the more memory > it's taking up on the server. I thought cookies might be used in such cases. > I don't usually use cookies, because ColdFusion has an configuration option > of storing session data in the system registry (windows version obviously)... > which alleviates the problem of running out of memory via the session scope. > > Have I completely missed your point? :) Nope, we're just off track :) Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
