Re^4: Perl Hash vs BerkeleyDB vs MySQL

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).

Comment on Re^4: Perl Hash vs BerkeleyDB vs MySQL

Replies are listed 'Best First'.
Re^5: Perl Hash vs BerkeleyDB vs MySQL by perrin (Chancellor) on May 09, 2006 at 16:13 UTC
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.	[reply]
Re^6: Perl Hash vs BerkeleyDB vs MySQL by pajout (Curate) on May 10, 2006 at 07:45 UTC
Oh, thanks for info. I believed my chief when we developed some software, so I thought that his usage of BDB is optimal and I did not observed more and more about BDB.	[reply]