Using TDB for glib/gobject applications

[Christian Hergert]

Hi Simo,

I wanted concurrent transactions so I could have various threads doing
work independently and maintain their own transaction for integrity.

Nested transactions really are not that important to me.

For example, I'm writing an RSS/Atom parser and storage system.
Multiple keys may be touched during an update process.  With N_CPU
threads running concurrently, it would be nice for each thread to have
their own transaction.  Whether that concurrent control actually happens
at the TDB level isn't too important I guess.

Currently, I'm maintaining that concurrent control in Catalina. I used
the message passing layer in my threading library iris[1] to essentially
do the same thing as a reader/writer lock for the active transaction.
Upon completion/failure of a previous transaction, the set of messages
for the next transaction are processed.

Anyway, I mostly just wanted to say thank you for such an easy to use
storage layer.  It took about half as much code as BDB. :-)

[1] http://git.dronelabs.com/iris/about/

-- Christian

On Tue, 2009-06-23 at 20:23 +0000, simo wrote:
> On Mon, 2009-06-22 at 01:55 -0700, Christian Hergert wrote:
> > Hi Folks,
> > 
> > I recently put together an object data-store for applications using
> > glib/gobject and had originally used BDB.  However, due to the superior
> > licensing of TDB I decided to switch.
> > 
> > Someone had mentioned that I should send you guys a message about it in
> > case anyone would find it useful.  I have a succinct blog post on it
> > here[1].
> > 
> > It supports serialization of basic types such as ints, doubles, and
> > strings as well and GObjects (members are key/value pairs).  If you
> > don't want serialization it can work with buffers directly too.  If
> > desired, it can transparently compress and decompress using zlib.
> > 
> > However, the one feature that was missing from TDB that I implemented
> > was concurrent transactions.  Is there any plan to do this within TDB
> > directly?  Also, my layer on top is primarily asynchronous.
> > 
> > [1] http://audidude.com/blog/?p=250
> > 
> > Thanks for reading!
> 
> Christian,
> very nice job.
> 
> About TDB concurrent transactions, do you mean nested transactions or
> really concurrent transactions ?
> 
> Concurrent transactions are basically impossible with TDB, how would you
> handle 2 separate transaction create an object with the same key ?
> 
> Concurrent transaction would be somewhat possible if we had a way to
> restrict a transaction to act only on keys with a specific prefix,
> maybe, but that seem a lot of work for little gain.
> 
> In what cases do you feel the need for concurrent transactions ?
> 
> Simo.
>