Model has a small possibility because of replication latency. about phalcon

[VeryStrongFingers]

Logistically it would make more sense to override the Model methods 'create'/'save' to temporarily change the read connection service for these methods.

Altering the code base to account for anyone running a master-slave database infrastructure by 'reading' from the 'write' DB service doesn't make the most sense out of all possible solutions, in my opinion.

Based on the code at https://github.com/phalcon/cphalcon/blob/c8d4916bbfd0cb18395fe25d8c5a663fc5077d8f/phalcon/mvc/model.zep#L2959
You could do something like

namespace Custom;

class Model extends \Phalcon\Mvc\Model {
    public function create($data = NULL, $whiteList = NULL)
    {
        $originalReadService = $this->getReadConnectionService();
        $this->setReadConnectionService($this->getWriteConnectionService());
        $result = parent::create($data, $whiteList);
        $this->setReadConnectionService($originalReadService);
        return $result;
    }
}

[dschissler]

@sergeyklay Can we add this to the 4.0 milestone? We can evaluate it later for its validity. It seems though that it could eliminate some rare gnarly impossible to reproduce race conditions.

[guweigang]

Maybe we should not check if record exists, it's not just a master-slave latency problem. Even using the same connection here, unless you use select...for update under a transaction，or else you can not avoid this 'cause of concurrency. @ifsnow @Mechzeit

Sent from my OnePlus ONEPLUS A5000 using FastHub

[acmenna]

Master-slave setup does not work with transactions either. If a transaction is active, all reads should be kept in master regardless the read connection. Doctrine has some cool rules to handle all these scenarios mentioned in this issue. I marked in bold the most important one that will covered the latency and the transaction issue.

http://www.doctrine-project.org/api/dbal/2.0/class-Doctrine.DBAL.Connections.MasterSlaveConnection.html

Slave if master was never picked before and ONLY if 'getWrappedConnection' or 'executeQuery' is used.
Master picked when 'exec', 'executeUpdate', 'insert', 'delete', 'update', 'createSavepoint', 'releaseSavepoint', 'beginTransaction', 'rollback', 'commit', 'query' or 'prepare' is called.
If master was picked once during the lifetime of the connection it will always get picked afterwards.
One slave connection is randomly picked ONCE during a request.

[guweigang]

@acmenna Agree. But I don't think this could help exists() before doLowUpdate.