I met the same problem just now.
mariadb 10.4
Centos 7
php5.6

 mysqli::begin_transaction(): This server version doesn't support 'READ WRITE' and 'READ ONLY'. Minimum 5.6.5 is required in /data/BPlatform/common/lock/MySqliLock.php on line 53

it was good before upgrading to mariadb 10.4 (was mysql 5.6)

Same issue even when using two different configurations. It would appear Oracle made their own bug report and properly fixed their code too: https://bugs.mysql.com/bug.php?id=68187

Configuration 1:
----------------------
MariaDB Version: 10.1.35
PHP version: 7.2.16
OS: CentOS 7

Configuration 2:
----------------------
MariaDB Version: 10.1.37
PHP version: 7.2.12
OS: Win10

Recommendation:
-----------------------
Follow in MariaDB's footsteps and check for the fake version number, then remove if it exists. See MariaDB's sql-common/client.c:  https://github.com/MariaDB/server/commit/c50ee6c23dbeb090963580754bec2f0a96ac0557#diff-5b45fa673c88c06a9651c7906364f592

What does mysqli_get_server_version($mysqli) or $mysqli->server_version return? 50505 I assume? And this has been the case since MariaDB 10.0, right? It's not new?

Because, to fill in the blanks that @duckwebdev saw, MariaDB returns a half-hardcoded version number (string) like "5.5.5-10.5.0". Which is a nuisance - it should be faking the corresponding MySQL version, not a fixed 5.5.5. Which is to say nothing about how hacky this was to fix the original problem. Sigh.
https://github.com/MariaDB/server/blob/826f9d4f7e99973cafe7654697d7c50b8b64b76b/include/mysql_com.h#L41

PHP could detect the magic "5.5.5-" string as their client does, but the truth is that since 10.0 their versioning scheme is incompatible with MySQL's. Like how 10.0 is based on the 5.6 series and so does not support 5.7 (or future) features, even though 10.0 >= 5.7. Which means to get it absolutely right PHP would need different version number checks; for example, transactions' READ WRITE/READ ONLY requires MySQL 5.6.5, which presumably will be somewhere (I can't find where) in the MariaDB 10.0 *and* 10.1 series. Double sigh.


...why couldn't they have done it properly like Percona...


Or... we could sweep the issue under the rug and remove version checks for older stuff - after all 5.6.5 was released April 2012, which is back in the PHP 5.3 era.

Server version: 10.1.38-MariaDB-0+deb9u1 Debian 9.8

var_dump($mysqli->server_version); // int(50505)

This also causes 8 test to fail.

mysqlnd implements the MySQL Client/Server protocol. If MariaDB doesn't follow the reference implementation then this is a problem of MariaDB, not of mysqlnd.
I am going to revert this patch.

A little bit harsh but I understand.

My only question than is why is mysqlnd is not doing what We ask it to do, not using transaction if MariaDB support it at version 10.3 ?

From what I can know of the protocol there is nothing in the protocol that say check the version number before doing a LOCK. 

Not that I am a fan of MariaDB to change the versioning schema, but there probably should be a other way in MySQL and MariaDB to find what features is available in the current server.

I don't know if this could help.

If I do a HELP 'lock'; It return this.
And we can see what is supported by the current version of the server.

We should probably ask MySQL and MariaDB to have a more easy to parse definition of theirs statements.

David
---------------------------------------------------

Syntax:
LOCK TABLES
    tbl_name [[AS] alias] lock_type
    [, tbl_name [[AS] alias] lock_type] ...

lock_type:
    READ [LOCAL]
  | [LOW_PRIORITY] WRITE

UNLOCK TABLES

MySQL enables client sessions to acquire table locks explicitly for the
purpose of cooperating with other sessions for access to tables, or to
prevent other sessions from modifying tables during periods when a
session requires exclusive access to them. A session can acquire or
release locks only for itself. One session cannot acquire locks for
another session or release locks held by another session.

Locks may be used to emulate transactions or to get more speed when
updating tables. This is explained in more detail later in this
section.

LOCK TABLES explicitly acquires table locks for the current client
session. Table locks can be acquired for base tables or views. You must
have the LOCK TABLES privilege, and the SELECT privilege for each
object to be locked.

For view locking, LOCK TABLES adds all base tables used in the view to
the set of tables to be locked and locks them automatically. If you
lock a table explicitly with LOCK TABLES, any tables used in triggers
are also locked implicitly, as described in
http://dev.mysql.com/doc/refman/5.5/en/lock-tables-and-triggers.html.

UNLOCK TABLES explicitly releases any table locks held by the current
session. LOCK TABLES implicitly releases any table locks held by the
current session before acquiring new locks.

Another use for UNLOCK TABLES is to release the global read lock
acquired with the FLUSH TABLES WITH READ LOCK statement, which enables
you to lock all tables in all databases. See [HELP FLUSH]. (This is a
very convenient way to get backups if you have a file system such as
Veritas that can take snapshots in time.)

URL: http://dev.mysql.com/doc/refman/5.5/en/lock-tables.html