Rubyists,
Am in the middle of a big technical decision of whether going with:
Questions:
- can Madeleine support multiuser concurrent access? i.e. multiple
instance of the client app can be run simultaneously
- can Madeleine support ACID transactions?
Note that DyBase can support the above features…
My requirement are:
- simple
- native OO
- small footprint
- fast
- multiuser concurrent access
- ACID (nice but not really critical)
Application calls for a fast, embeddable fast storage with multiple
concurrent access. Maximum number of records do not exceed 10,000.
Updates, writes, deletes will be fast and furious. Activity will be
extremely spiky.
Comments, experiences?
···
–
a8888b.
d888888b.
8P"YP"Y88 Wai-Sun “Squidster” Chia
8|o||o|88 Sr. Technical Consultant (RHCE)
8’ .88 OpenSource Development
8._.' Y8. Consulting & Integration d/8b. HP Services Malaysia
dP . Y8b.
d8:’ " ::88b d8" 'Y88b :8P ' :888 8a. : _a88P ._/"Yaa_: .| 88P| \ YP"| 8P . / \.___.d| .'–…__)8888P`._.’
"Fear the Penguins!"
Questions:
- can Madeleine support multiuser concurrent access? i.e. multiple
instance of the client app can be run simultaneously
Hi Wai-Sun,
Madeleine itself doesn’t have the concept of multiuser access or remote
clients, but if you for instance run one Madeleine “server” with a DRb
(Distributed Ruby) interface, then many DRb clients can work with it.
- can Madeleine support ACID transactions?
Yes, but with some restrictions. You can read more about this on the
Prevayler wiki:
http://www.prevayler.org/wiki.jsp?topic=DontINeedTransactions
My requirement are:
Madeleine’s got that for sure.
Typically smaller than with a database.
Yep.
- multiuser concurrent access
- ACID (nice but not really critical)
See above.
Application calls for a fast, embeddable fast storage with multiple
concurrent access. Maximum number of records do not exceed 10,000.
Updates, writes, deletes will be fast and furious. Activity will be
extremely spiky.
I think Madeleine will work for it, you’ll just have to start by making
sure that you can fit a 10,000-record array in memory.
/Anders
···
— Wai-Sun Chia waisun.chia@hp.com wrote:
=====
Anders Bengtsson ndrsbngtssn@yahoo.se
Stockholm, Sweden
Gå före i kön och få din sajt värderad på nolltid med Yahoo! Express
Se mer på: http://se.docs.yahoo.com/info/express/help/index.html
Beware: multiple DRb clients talking to the same remote object will make
multiple concurrent method calls - each incoming request is handled as a
separate thread on the same object at the server side.
Therefore DRb doesn’t solve any concurrency issues you may have.
With Madeleine, I believe that serialising access to the database is your
own responsibility - e.g. while reading a group of objects, you want to be
sure that nothing is changing under your feet. But it’s so fast that having
a global mutex for database access isn’t too big a penalty in many cases.
Regards,
Brian.
···
On Fri, May 30, 2003 at 04:56:08PM +0900, Anders Bengtsson wrote:
— Wai-Sun Chia waisun.chia@hp.com wrote:
Questions:
- can Madeleine support multiuser concurrent access? i.e. multiple
instance of the client app can be run simultaneously
Hi Wai-Sun,
Madeleine itself doesn’t have the concept of multiuser access or remote
clients, but if you for instance run one Madeleine “server” with a DRb
(Distributed Ruby) interface, then many DRb clients can work with it.
Madeleine itself doesn’t have the concept of multiuser access or
remote
clients, but if you for instance run one Madeleine “server” with a
DRb
(Distributed Ruby) interface, then many DRb clients can work with
it.
Beware: multiple DRb clients talking to the same remote object will
make
multiple concurrent method calls - each incoming request is handled
as a
separate thread on the same object at the server side.
Therefore DRb doesn’t solve any concurrency issues you may have.
Since all “writes” to Madeleine have to go through the
execute_command() method, which is synchronized, this won’t be a
problem.
With Madeleine, I believe that serialising access to the database is
your
own responsibility - e.g. while reading a group of objects, you want
to be
sure that nothing is changing under your feet. But it’s so fast that
having
a global mutex for database access isn’t too big a penalty in many
cases.
Yes, when reading you have to do your own synchronization if you need
it.
Maybe I should add a way to access Madeleine’s big write lock from the
outside, if anyone wants to solve things the “global mutex” way.
/Anders
···
— Brian Candler B.Candler@pobox.com wrote:
=====
Anders Bengtsson ndrsbngtssn@yahoo.se
Stockholm, Sweden
Gå före i kön och få din sajt värderad på nolltid med Yahoo! Express
Se mer på: http://se.docs.yahoo.com/info/express/help/index.html
Since all “writes” to Madeleine have to go through the
execute_command() method, which is synchronized, this won’t be a
problem.
As you say, reads don’t benefit from this protection. It might not be as bad
as I thought: I was thinking that if you follow a reference from object A to
object B, and the reference was changed in the mean time, you could end up
pointing to a garbage object B. But actually you would be holding a
reference to the object yourself, so it wouldn’t be garbage-collected.
But you could still end up with inconsistent reads, i.e. the objects are in
a state which is neither how they were before execute_command nor after it,
if execute_command is midway through its processing.
Maybe I should add a way to access Madeleine’s big write lock from the
outside, if anyone wants to solve things the “global mutex” way.
Sure. Perhaps you could add a wrapper for the traditional model of a shared
read lock, and an exclusive write lock. (I’m not quite sure how to implement
this; I guess the read lock manager would have to grab the write lock
whenever 1 or more people asked for a read lock, and return it when this
number went to 0, but you want a way to prevent starvation when someone is
waiting for a write lock, e.g. no new readers are allowed until the write
has had a chance)
Cheers,
Brian.
···
On Fri, May 30, 2003 at 06:13:56PM +0900, Anders Bengtsson wrote:
Brian Candler wrote:
Maybe I should add a way to access Madeleine’s big write lock from the
outside, if anyone wants to solve things the “global mutex” way.
Sure. Perhaps you could add a wrapper for the traditional model of a shared
read lock, and an exclusive write lock. (I’m not quite sure how to implement
this; I guess the read lock manager would have to grab the write lock
whenever 1 or more people asked for a read lock, and return it when this
number went to 0, but you want a way to prevent starvation when someone is
waiting for a write lock, e.g. no new readers are allowed until the write
has had a chance)
There’s a little-known implementation of shared locks in the Ruby
distribution called sync.rb, which we’ve already used for some
experiments with Madeleine. It has slightly worse performance than
Mutex, but enables some interesting performance optimizations.
/Anders
···
–
A n d e r s B e n g t s s o n | ndrsbngtssn@yahoo.se
Stockholm, Sweden |
