Thanks, that’s an excellent question. In fact, I might have to add this information to the documentation.

I am not certain how you plan to dockerize your WordPress, but if all the WordPress containers connect to a single MySQL database and a single wallet, you will not have any problems.

DEPOSITS:

You can designate one instance to be responsible for receiving notifications. This instance will be inserting deposit transactions into the DB. All other instances will immediately see the transactions in the DB.

Alternatively, if you prefer, you could have more, or all the instances receive the notifications, if you think this is needed. To do this, you would modify your curl command so that it is now two or more curl commands, running in parallel with the Unix shell & operator. This would look something like:

walletnotify=curl -sk 'http://FIRST.IP.ADDRESS.HERE/?__wallets_action=notify&__wallets_symbol=BTC&__wallets_notify_type=wallet&__wallets_notify_message=%s&__wallets_api_version=3' & curl -sk 'http://SECOND.IP.ADDRESS.HERE/?__wallets_action=notify&__wallets_symbol=BTC&__wallets_notify_type=wallet&__wallets_notify_message=%s&__wallets_api_version=3'

If a transaction has already been written to the DB, then another instance attempts to write it too, the transaction row will simply be updated with the latest confirmation count. Only the first instance that inserts the transaction will send a notification email.

WITHDRAWALS and internal transfers:

Operations that modify the database are all guarded with table locks, so consistency is guaranteed even if several instances are hitting the DB at once. For example, a typical run of the function cron_execute_pending_withdrawals() would do the following:

1. lock the transactions table
2. read in a batch of pending withdrawals
3. try to execute them, and send email notifications as needed
4. unlock the table

Any other instances running cron would have to wait for the DB to unlock, so there is no danger of double-spends. The same is true for internal transfers (moves).

You might still prefer to have one instance be the only one that runs cron tasks. In that case, you cannot use the plugin’s settings to disable cron jobs from the other instances, as all instances share the same DB and therefore the same wp_options table (settings). You will have to use the DISABLE_WP_CRON constant in all the instances except the one that you use for running the transactions.

I hope I have answered your question adequately.

I have moved this to a new thread as it is unrelated to the previous thread.

Please let me know if you have any more questions.

Also, if you ever attempt to run the plugin in multiple containers, I would love to hear about your experience, and if you encountered any difficulties.

with regards