| Re: Best strategy for creating an application scoped variable? [message #172048 is a reply to message #172043] |
Fri, 28 January 2011 14:00   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 1/28/2011 2:30 AM, Denis McMahon wrote:
> On 28/01/11 03:24, Jerry Stuckle wrote:
>> On 1/27/2011 9:40 PM, Peter H. Coffin wrote:
>>> On Thu, 27 Jan 2011 16:08:01 -0800 (PST), laredotornado(at)zipmail(dot)com
>>> wrote:
>
>>>> I'm using PHP 5.2. I would like to populate a hash from a database
>>>> query. The hash should be available to all users of the application
>>>> and would only be updated very occasionally. The database query is
>>>> expensive, and I would prefer only to run it once, whenever PHP was
>>>> restarted, or on the rare occasion when the database data changed.
>>>> What is the best strategy for implementing this hash?
>
>>> I'm confused. What "hash" do you want to "populate"? Do you just want to
>>> stick a pregenerated value in a table? Maybe you need an insert/update
>>> trigger?
>
>> That was my thought - create a table in the database with the required
>> information and update it based on a trigger. Much easier than trying
>> to use shared memory or the like.
>
>> I guess an alternative would be to create a PHP file from the generated
>> data and include it where necessary. But there's always the problem of
>> updating it when the web server restarts (PHP doesn't "restart" - it
>> starts every time a request is made for a PHP file - and only then).
>
> I guess the included file could be created with a cron job, say every 6
> hours or so?
>
> To try and minimise file access conflicts, it might be best to create it
> with a temporary name and then using a shell "mv temp_file actual_file"
> at the end of the cron job.
>
> However, I'd have thought that copying the query results into a new
> table would be the best answer, I guess it would be a static snapshot of
> the expensive query, and then access it as "select * from<table>",
> maybe running a cron process to generate it every 6 / 12 / 24 / whatever
> hours.
>
> Or create an extra table with a time field that you update when you run
> the query, and check this field every time you access the data, if the
> data is older than some defined limit, call the expensive query to
> update the snapshot table.
>
> Rgds
>
> Denis McMahon
I wouldn't run a cron job. I would use the database tools to run the
query as necessary.
And there are several ways to protect the file, if you do write to a
file. For instance, lock the file before writing and before including.
But I think creating a table with the results would be much better.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]