[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANN] gzochi project development release 0.10

From: Amirouche Boubekki
Subject: Re: [ANN] gzochi project development release 0.10
Date: Sun, 14 Aug 2016 10:15:17 +0200
User-agent: Roundcube Webmail/1.1.2

On 2016-08-14 01:23, Julian Graham wrote:
On Sat, Aug 13, 2016 at 3:33 PM, Amirouche Boubekki
<address@hidden> wrote:
Based on a few tests wiredtiger is faster than berkeley db. You might
consider having a look at it.

I've looked at WiredTiger before - and this Guile integration looks
very nice - but I decided not to go any further with an integration
because it only supports (as far as I can tell) an optimistic
transactional concurrency model, and my belief is that game
application workloads are likely to benefit more from a pessimistic
model in which concurrent write locks on the same record are
serialized. That is to say, the restart-on-conflict workflow in an
optimistic model is expensive, so it's only worth it if you expect
write contention to be rare. If you expect it to be frequent, you're
going to waste a lot of CPU cycles re-executing transactional code.

Ah, you are probably right. I did not know what optimistic locking is.

However, that's just my intuition: If you'd like to integrate it and
test it out, the storage engine SPI is easy to implement!

TBH, gzochi seems awesome but I don't have an immediate need for it.
Except maybe something. You do store task that must be executed in the database and somehow when it's time for them to execute you schedule them? Is that correct?
Is that correct that the task queue is persisted to disk?

Amirouche ~ amz3 ~

reply via email to

[Prev in Thread] Current Thread [Next in Thread]