Share data between cron-job and webserver executed PHP scripts

Question

The one below is a common way how a master and a child script do data sharing:

cron job -- schedule --> master script

HTTP request -- trigger --> child script

master script --> [database] <-- child script

But is it possible to them to share the data using any of these below, instead of the database?

• global variable
• system storage
• session storage
• memcache / apc / any other thing like these

Answer 1

1. global variable - no
2. system storage (from comments: this is command line) - no because that would involve one launching the other, and still be one-way...
3. session storage - yes, using named session, but this will resort to files by default (can be configured to use shm and then in-memory...)
4. memcached - yes
5. apc - yes, but will require explicit configuration to enable in cli sapi
6. files - yes. And to speed things up, you can use ramfs to store files in an in-memory filesystem.
7. sockets - yes (make one of the a listener and connect from another)
8. database - yes (why not, actually?)

In case i left anything out, you can search for php interprocess communication

Answer 2

1. not possible
2. what do you mean with system storage?
3. not possible
4. memcach:would be no problem if both applications somehow know the key to the value, apc: not possible

Answer 3

The only way left is fs. Either socket as DaveRandom suggests, or a simple file.

Why don't you want to use the database? What are you trying to do specifically?

Answer 4

Of course, you can connect to MySQL servers from cron-job (php-cli) executed scripts just like how you can from the webserver, assuming that the php.ini for command-line has the database library loaded.

If you don't want to use database, you can either set up sockets or use temporary passthrough files. But using the database would be the most efficient and tidy way.

Answer 5

I second a file solution:

• It's simple to code/understand/maintain
• It's crash foolproof, you will not loose content when there is a problem.
• It's protected against concurrents writes
• It's as fast as memory if your OS decides it needs to be cached for frequent access. (Usually it's simpler/safer/faster to not try to replace OS optimisation.)