Return to Answer

There's an alternative to threads.

The use case you explain doesn't seem to need be synchronous.

So you could make a script that reads a database and writes in a temporary table. Such a script recieves the connection info via parameters passed to it. That way you can schedule cron jobs with the same scripts but different databases that run in parallel at a given time.

A second job would poll to see if those jobs finished and then do the comparison work and store the results in a single-point table.

The data-input form could check with that pre-processed tables instead and if the data is too old (configurable), tell the user to wait for a notification in a notification area to give them a sense of workflow.

It's just a possible alternative.

Also if the input form show the user a drop-down list of existing names you can save the user confirmation time.

There's an alternative to threads.

The use case you explain doesn't seem to need be synchronous.

So you could make a script that reads a database and writes to a temporary table. Such a script would recieves the connection info via parameters passed to it. That way you can schedule cron jobs with the same scripts but different databases that run in parallel at a given time.

A second job would poll to see if those jobs finished and then do the comparison and store the results in a single-point table.

The data-input form could check with that pre-processed tables instead and, if the data is too old (configurable), tell the user to wait for a notification in a notification area to give them a sense of workflow.

It's just a possible alternative.

Also if the input form shows the user a drop-down list of existing names you can save the user confirmation time.

There's an alternative to threads.

The use case you explain doesn't seem to need be synchronous.

So you could make a script that reads a database and writes in a temporary one. Such a script recieves the connection info via parameters passed to it. That way you can schedule cron jobs with the same scripts but different databases that run in parallel at a given time.

A second job would poll to see if those jobs finished and then do the comparison work and store the results in a single-point table.

The data-input form could check with that pre-processed tables instead and if the data is too old (configurable), tell the user to wait for a notification in a notification área to give them a sense of workflow.

It'a just a possible alternative.

Also if the input form show the user a drop-down list of existing names you can save the user confirmation time.

There's an alternative to threads.

The use case you explain doesn't seem to need be synchronous.

So you could make a script that reads a database and writes in a temporary table. Such a script recieves the connection info via parameters passed to it. That way you can schedule cron jobs with the same scripts but different databases that run in parallel at a given time.

A second job would poll to see if those jobs finished and then do the comparison work and store the results in a single-point table.

The data-input form could check with that pre-processed tables instead and if the data is too old (configurable), tell the user to wait for a notification in a notification area to give them a sense of workflow.

It's just a possible alternative.

Also if the input form show the user a drop-down list of existing names you can save the user confirmation time.

There's an alternative to threads.

The use case you explain doesn't seem to need be synchronous.

So you could make a script that reads a database and writes in a temporary one. Such a script recieves the connection info via parameters passed to it. That way you can schedule cron jobs with the same scripts but different databases that run in parallel at a given time.

A second job would poll to see if those jobs finished and then do the comparison work and store the results in a single-point table.

The data-input form could check with that pre-processed tables instead and if the data is too old (configurable), tell the user to wait for a notification in a notification inbox to give it a sense of workflow.

It'a just a possible alternative.

Also if the input form show the user a drop-down list of existing names you can save the user confirmation time.

There's an alternative to threads.

The use case you explain doesn't seem to need be synchronous.

So you could make a script that reads a database and writes in a temporary one. Such a script recieves the connection info via parameters passed to it. That way you can schedule cron jobs with the same scripts but different databases that run in parallel at a given time.

A second job would poll to see if those jobs finished and then do the comparison work and store the results in a single-point table.

The data-input form could check with that pre-processed tables instead and if the data is too old (configurable), tell the user to wait for a notification in a notification área to give them a sense of workflow.

It'a just a possible alternative.

Also if the input form show the user a drop-down list of existing names you can save the user confirmation time.