Robert Cummings <[EMAIL PROTECTED]> wrote:>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 :) Thanks! :) > > 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. No worries. I'd still like to hear (from anybody, really) what specific business examples they have where this "share nothing" concept came into play. Also, I promise to go out and Google it to try and find out for my self, as soon as my work load dies down. I've got three projects going simultaneously and four more "little ones" (I hope) on the way. I'm sure most of you can relate. :) But, as long as people on this list are willing to discuss things with me and answer my questions, I'd greatly appreciate it! :) >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. Of course. Jochem, feel free to jump in here if you've got time. :) Your comment may not have *really* applied to my specific situation, but I'm intrigued now. :) > 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. Okay, I can see what you mean there. Only that *one* machine has the data cached, so if you were to want to spread the load out over several machines, they'd all have to cache the same configuration and any time it changed they'd all have to re-cache it, since none of the machines knows about the others... that kind of thing? >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. Okay, I think I'm starting to understand now. Right now, I'm working on a very large CF project for a national company and I'm trying to think of where I might apply the idea of the "share nothing" rule. Nothing leaps to mind, but it may when I least expect it. I'd still be interested in hearing from anyone who's applied this idea on any scale. Sometimes I've got to be beaten over the head with something before I can get my mind around it, so examples would help. Heck I'm *just now* starting to get to the "Ah-ha!" stage of OO programming (and I'm loving it, by the by), but it took what seems like forever to get there. You know? > 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. I think you've hit the nail on the head there, but I'm sorta glad the subject's come up since I'm learning about a concept that I've not used before. Is it mostly used for purposes of scalability? It seems like it might be that way. > 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. Thanks so much Rob for sharing your knowledge with me. :) It's very nice to see that folks on the list seem to be patient and responsive. Have a great day! -Chris __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
