Re: [PEPr] Proposal for PHP::ApplicationVars

Hi Davey, On Wed, 2003-12-24 at 11:38, Davey wrote: > FYI, Pollita (Sara Goleman) mentioned a PECL package for registering new > superglobals, that I believe she is working on. I could easily tie > $_APPLICATION (my preffered variable name) to my class. I thought someone else had already written one? Though, if you're in a situation where you can install an extension like that, you could probably install Turck MMCache or SRM and have it all. Either name works for me. > > Also, this was a proof of concept, I will add flocking. However, my main > concern here is that standard $_SESSION variables are tied to the > APPLICATION. The only way around this is using a seperate file for > Application vars, not a big problem... just need to re-write (which I've > mostly done anyways) the standard PHP Session handling into userland > code + storing $_SESSION[ASID] in its own file. Probably the best > solution actually. That's what I have with my wrapper. By default it supports storage in $_SESSION, like yours, and also, Cache_Lite and Cache (best with a MySQL heap table). Via the same interface other "drivers" can easily be added. I'm adding a native mysql/heap driver to see how it compares to Cache_Lite. Admittedly, the added abstraction adds a little overhead but why rewrite Cache/Cache_Lite? > > I would actually like to have what ColdFusion (MX only?) has, which is > that you need to tell it to lock the application vars stuff, otherwise > it assumes the data can be "corrupted". I mean, a lot of stuff that this > will be used for, would prefer speed to data accuracy. I believe it goes back to at least CF3, though cflock got some new attributes and the best practice usage changed in 4.5.0(?). But, yes, that's exactly why application vars are not implicitly locked. (I don't think it changed at all in MX, though I haven't used CF from since 5.0.) _But_, CF's application var retrieval works differently than this system, even putting aside where they are stored. In CF individual vars are pulled out of server RAM as they are called while the pcode (<=CF5) or compiled Java (>=MX) is run; the way we're doing it, they are all pulled out of storage ahead of time and loaded into the request. We're working on a copy of the application var, so the time to lock is when that copy is made, the file read. To really emulate CF app vars, with per access locking, would require per access reading, which would result in really poor performance if implemented in userland code. And to _really_ get CF-style application behavior would require the use of a common file to setup your application name. Ideally, an auto_prepend file like CF's default prepend file, Application.cfm, that your app knows to travel up the tree to, so it's settings cascade down to all the subdirs below it, allowing them all to share the application vars. > Again, using a database, is the BEST solution all round, that way > sessions are NOT tied to an Application and file locking is unnecessary. I think shared memory is theoretically better (shmop/sem) but a db has some compelling advantages in ease of setup and portability. Plus, locking is already handled by the db and you could easily use memory resident tables. I just can't see that this isn't adding another cache class when there are already two in PEAR. -Alan