I don't understand your shared memory comment. MySQL is implemented as multiple threads which share memory, but they don't share memory with your program. BerkeleyDB does use a shared memory cache, and it runs resident in your process, so you are accessing data directly from shared memory, unlike MySQL where you access it over a socket.

My English is not perfect, surely :>)
I'v mentioned "other conception", because necessity of deadlock daemon, for instance. In _my_ point of view it is up to developer to manage that deadlocks, sql machines behave in more standard way and they do it without additional effort. Aditionally, I know table-locking and row-locking in sql, but no page-locking.
Ad "shared memory" - if you have two sepparated processes, using BerkeleyDB, there is no easy chance to share some memory with loaded data between those processes. Oppositely, when you have two sepparate processes using two connections into sql database, the sql machine can use shared memory to satisfy both connections (querying the same, of course).

If you don't want to run the provided deadlock daemon, just use database level locking. It performs very well and doesn't require any work from the developer.

if you have two sepparated processes, using BerkeleyDB, there is no easy chance to share some memory with loaded data between those processes.

Sorry, this is not correct. BerkeleyDB uses a shared memory cache, which it manages automatically. If two processes are accessing the same data, it is very likely that it will come out of the shared memory cache. You can read more about it here.

It may be that you were using it through a legacy interface like DB_File and not setting the options for using the shared memory cache. They're just some options you use when opening the database file. After that, the sharing is automatic.