> I found CodernityDB <
http://labs.codernity.com/codernitydb/>
Most NoSQL databases are primarily designed as a key:value storage. Its main
goal is not a consistency. You might have problems with ordering. I'd suggest
some relational database.
I'll look into Gadfly. It might be a good candidate. Stay tuned.
> But before I start pulling my hair, kindly please give me enlightenment :
> Is a 'transactional' feature a must for snakeMQ persistence storage ?
Yes and no. If a message is about to be stored then the Messaging calls
QueuesStorage.push(). What is exactly going to happen in the push() is
absolutely up to the storage driver. So if you can store the message with a
single e.g. SQL command then you don't need a transaction. If you have to call
more commands to read or modify the database then you need atomicity and even
some database locking. But again it depends on the database mechanism design.
Maybe a little bit uselessly complicated answer :-) Current snakemq storage
handlers does every operation with a single database command. If you follow the
same approach then you don't have to care about transactions.
David