unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Julian Graham <joolean@gmail.com>
To: Amirouche Boubekki <amirouche@hypermove.net>
Cc: Guile Users <guile-user@gnu.org>,
	guile-user <guile-user-bounces+amirouche=hypermove.net@gnu.org>
Subject: Re: [ANN] gzochi project development release 0.10
Date: Sat, 13 Aug 2016 14:33:26 -0400	[thread overview]
Message-ID: <CANdC_RBKQsja55p=KRRAhcV0gAFz3F0FhqwPUDyKRCjT3wsw-A@mail.gmail.com> (raw)
In-Reply-To: <fa31370e7cedebfd4041f7a07d33da40@hypermove.net>

Hi Amirouche!

> Can you explain in more details what this B+tree based storage engine is?
> And what is used for?

Sure!

Some context: gzochi is an application server for games written in
Guile. It provides various services to the applications that it hosts,
including data storage. The underlying implementation of the data
store (the "storage engine") is configurable - the framework comes
with a Berkeley DB storage engine and an in-memory storage engine.
(And you can write your own, if you wish.)

All of the data structures manipulated by a game running in the gzochi
container - the game's "object graph" - are serialized and persisted
to the data store. The container guarantees a consistent view of the
object graph to each "task" that runs as part of the game, and it
handles changes to the graph transactionally. It's up to the storage
engine implementation to make sure that every transaction is isolated
from every other transaction, that deadlocks are resolved properly,
that each transaction either commits or rolls back atomically, etc.
The Berkeley DB-based storage engine relies on BDB for those things.
The in-memory engine uses a B+tree and intentional (R/W) locking to
implement transactions.

The B+tree storage engine has a second function when running gzochi in
a distributed / high-availability configuration: It's used to cache a
subset of the object graph on each node in the cluster while that node
is executing game code that manipulates that part of the graph. (In
this configuration, the centralized "meta server" is responsible for
storing and retrieving the canonical version of the object graph.)

Does that answer your question?


Regards,
Julian



  reply	other threads:[~2016-08-13 18:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-13  2:29 [ANN] gzochi project development release 0.10 Julian Graham
2016-08-13 15:28 ` Amirouche Boubekki
2016-08-13 18:33   ` Julian Graham [this message]
2016-08-13 19:33     ` Amirouche Boubekki
2016-08-13 23:23       ` Julian Graham
2016-08-14  8:15         ` Amirouche Boubekki
2016-08-15 17:12           ` Julian Graham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANdC_RBKQsja55p=KRRAhcV0gAFz3F0FhqwPUDyKRCjT3wsw-A@mail.gmail.com' \
    --to=joolean@gmail.com \
    --cc=amirouche@hypermove.net \
    --cc=guile-user-bounces+amirouche=hypermove.net@gnu.org \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).