Announce: BarricaneDB v0.2.0 - a transparent object persistence mechanism for NodeJS.

[Chris Dew]

BarricaneDB - a transparent object persistence mechanism for NodeJS.

GitHub - https://github.com/chrisdew/barricane-db
Documentation - http://www.barricane.com/barricane-db/

Status v0.2.0 - Just about works - there will be bugs.

BarricaneDB is a persistence layer for [NodeJS](http://nodejs.org/)
which was developed to meet my following requirements:

* My app's state exists as a heap of objects in RAM. I just want to
be able to shutdown my app and get that same heap of objects the next
time I start my app.
* I don't want to have to add or change more than a dozen lines of
code.
* I want a proper transaction log, so that the data is resilient
against application crashes.
* I want to be able to read the transaction log - I care more about
making my app easily debuggable than saving disk space.

BarricaneDB is a loose implementation of the [Prevalence](http://
www.ibm.com/developerworks/library/wa-objprev/) System Design Pattern,
as implemented in Java by [Prevaylor](http://www.prevayler.org/), but
for [NodeJS](http://nodejs.org/).

See the links at the top of the post, if you're interested.

Regards,

Chris.

P.S. Cross-posted to barricane-db, nodejs and prevayler-discussion -
apologies if this is a bit spammy.

[billywhizz]

this looks really interesting. along the lines of what i have been
putting together privately. if we could add a robust transaction log
and ACID it could be very useful indeed. Also, i think this statement
is wrong as a reason not to use:

You need to query your database from outside the NodeJS process - e.g.
Crystal Reports.

i don't see why you shouldn't be able to query it using javascript/
json over a socket. i do this a lot for in memory databases already.
it works really nice, although you have to be sure your queries don't
block the server process for long.

look forward to seeing more of this and hopefully will get a chance to
help out.

On Feb 10, 12:23 pm, Chris Dew <cms...@gmail.com> wrote:
> BarricaneDB - a transparent object persistence mechanism for NodeJS.
>
> GitHub -https://github.com/chrisdew/barricane-db

> Documentation -http://www.barricane.com/barricane-db/

>
> Status v0.2.0 - Just about works - there will be bugs.
>
> BarricaneDB is a persistence layer for [NodeJS](http://nodejs.org/)
> which was developed to meet my following requirements:
>
> * My app's state exists as a heap of objects in RAM.  I just want to
> be able to shutdown my app and get that same heap of objects the next
> time I start my app.
> * I don't want to have to add or change more than a dozen lines of
> code.
> * I want a proper transaction log, so that the data is resilient
> against application crashes.
> * I want to be able to read the transaction log - I care more about
> making my app easily debuggable than saving disk space.
>

> BarricaneDB is a loose implementation of the [Prevalence](http://www.ibm.com/developerworks/library/wa-objprev/) System Design Pattern,

[Chris Dew]

Hi, I thought 'billywiz' sounded familiar - I read this while looking
into fsync with NodeJS:

http://groups.google.com/group/nodejs/browse_thread/thread/630d7d20cbf22d14

* What's the best way of doing fsync in NodeJS (in 0.2.6 or 0.4.0)?

I could add durability to barricane-db. Consider a
'DB.flushToDisk(callback)' method, which calls back when all writes
cause *before* that point had been written AND an fsync had completed.

(Implementation thoughts - add a .transactionCount integer and
a .outstandingWritesByTransactionCount object to the DB and then place
each outstanding write in .outstandingWritesByTransactionCount on
write and remove them when completed. Then the fsync can be triggered
when there are no writes < [.transactionCount as of when
the .flushToDisk() was called]).

As far as I understand, the transaction log only needs one additional
feature to make it robust: DB.open() must be prepared for the last
line to be only partially written to disk, and therefore invalid JSON.

Is there something else I've missed here?

Your point about external queries is correct - I should change this to
say that there are no ODBC/JDBC drivers for BarricaneDB and that there
are never likely to be any.

* If 'DB.flushToDisk(callback)' would be useful to you, let me know
and I'll add it (and the handling of invalid JSON) next week. If you
have other ideas on a durability API, please let me know.

* Are there other features from your experience with in-memory
databases which could translate well to BarricaneDB?

All the best,

Chris.