Re^2: mod_perl best practice to consume dynamic file

Thank you for your thoughtful response!

File locking was me chief concern when creating this post, especially in an Apache environment that handles upwards of 100 requests per second. To me, it seemed rather foolish to proceed with my proposed solution without getting some feedback. Especially considering that the frequency with which it will update is an infrequent, predictable interval.

Out of curiosity, instead of using a JSON file, would manufacturing a perl script that I do() inside of my module be a better solution? I am not locked down to how the information is stored, I just need to be able to access it.

Thanks again!

Comment on Re^2: mod_perl best practice to consume dynamic file

Replies are listed 'Best First'.
Re^3: mod_perl best practice to consume dynamic file by Anonymous Monk on Jul 27, 2017 at 14:58 UTC
don't listen to this guy, he's the worst user on here.	[reply]
Re^3: mod_perl best practice to consume dynamic file by karlgoethebier (Abbot) on Jul 27, 2017 at 16:36 UTC
"...thoughtful response..." Caveat lector Regards, Karl ŤThe Crux of the Biscuit is the Apostropheť `perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'`Help	[reply] [d/l]
Re^3: mod_perl best practice to consume dynamic file by locked_user sundialsvc4 (Abbot) on Jul 27, 2017 at 18:36 UTC
Your OP does not elaborate as to how-and-where the modifications to the JSON come from. It implies that maybe you intend to cache the data in `mod_perl`’s persistent memory. But the trouble will be that none of the web-workers that might exist will safely know about the others, and so you could have inconsistent updates to the data. Like others have already suggested, I think that I would use a database. Even if you decide to store JSON in the database. Be sure to use a database server (and on-disk format, if applicable) that supports transactions so that you can, for example, reliably perform a `begin transaction...select...update...commit` cycle that will be atomic. If you wanted to stash the data in server-memory to avoid unnecessary traffic and decoding, you could include a server-timestamp in the table and do something along the lines of `select * from json_table where last_update_time > 'the last last_update_time you saw'`. (Also doing this in a transaction, which does a `commit` even though it doesn’t update anything.) If the query returns a row, you know it's an updated JSON-chunk that you need to process. Database transactions using an appropriate level of isolation will ensure that the activities of multiple workers will not interfere with one another or read inconsistent information. (When you update the table, if it includes a `last_update_time` field, use the SQL `NOW()` function so that the server, not you, provides the time-value used. Then, query to see what it was before committing the transaction.) If I may be candid, I would abandon the JSON-in-a-file notion, altogether. Timing-issues would be a royal PITA, and database transactions give you an easy and reliable way to avoid them completely.