Re: [ANN] gzochi project development release 0.10

[Amirouche Boubekki]

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.
> > https://framagit.org/a-guile-mind/guile-wiredtiger
>
> 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 ~ http://www.hyperdev.fr