First off, let me apologize to everyone for not responding last night. I got a bounce message back and I assumed (yeah yeah) that it had not made it to the list. Not long after writing this email, I noticed a difference in the example in the docs to my code. I was creating an object in the current name space, while the example was stuffing it into some apparently arbitrary name space (Bird::Global). For whatever reason, Getting the variable out of the confs name space is _required_ for this to function, but that is not documented; or if it is, I hadn't seen it anywhere yet, and certainly isn't stated in the example.
So, I got past that hurdle last night, but didn't come check the list mailbox again until this morning. I'll respond to some other points made below and in any other responses. On Thu, 2007-01-04 at 17:47 -0500, Jonathan Vanasco wrote: > On Jan 4, 2007, at 5:13 PM, Sean P Quinlan wrote: > > > The way the new version is designed, a 'client' object will cache > > the user objects (relatively small, name, email, phone etc) for > > users previously authenticated, using a session token as a key. > > Reading the document above, it seemed I would be able to create a > > client object at startup, which could cache 'currently' > > authenticated users (cleanup on the configured timeout), saving a > > lot of database accesses. As yet I have not been able to test the > > usefulness of this approach however as I can't seem to get off the > > ground, getting tangled with errors in configuration. > > you might want to re-think this approach entirely. > Well, the main reason I'm trying to do it this way in mod_perl is that it would take advantage of the way the base class already works. Even with no caching I would prefer this, as it allows my mod_perl modules to work as relatively thin wrappers on the base code. > your user object cache will be per-apache child. that means if you > startup with a cache, and have 5 children, they all clone from that > cache. but when you start updating / editing the information, the > memory gets unshared. new users will be authenticating against your > db for each child they use too. True. While I hadn't really considered that, given that some processes (like product QC) may have a user rapidly scanning over 100 pages in the course of a few minutes (well, unless something was abnormal ;), even this small gain is beneficial, if it isn't difficult to implement. > in other words, you're working your ass off for something that will > get you - at best - a marginal improvement. Well, since in the end all I needed to solve this problem was to add Foo::, most of the work was still in learning how to take advantage of PerlSections anyway, so no loss. > what you need is some sort of shared system that can support multiple > apache children (and possibly servers. you might actually want a > cluster at some point) Shared across children could be useful. But I would be surprised if sharing such small, transient objects across nodes would be worth the trouble to code. > some ideas: > a- screw db access concerns. use mysql to handle that sort of > access. i use postgres, and often do stuff like sessions, etc in > mysql -- its really fast on selects and where stability doesn't count. > b- cache your users in a daemon. stash your authenticated user data > in something like memcached, then just query that. its faster than > even mysql select, and super easy to implement. Interesting! I'll go look into it. Thanks! -- Sean P Quinlan <[EMAIL PROTECTED]>
