few questions about WriteBatch

[Ren Z]

I have few questions regarding WriteBatch:

1) Consider this:

one thread:

using (WriteBatch batch = new WriteBatch())
{
    for(int i=0; i<100; i++)
    {
        batch.Put(i.ToString(), i.ToString())
    }
    leveld_db.Write(batch);
}

parallel thread:

using (WriteBatch batch = new WriteBatch())
{
    for(int i=0; i<100; i++)
    {
        batch.Put(i.ToString(), (i+1000).ToString())
    }
    leveld_db.Write(batch);
}

Is there a guarantee that I won't end up with data like {10, 10} {11, 1011} ? (I.e. I expect that only one set or the other stays in db and not mixed, is this assumption correct?)


2) Somehow related:

If I get to make a lot of changes through a WriteBatch  and then write it all is there a guarantee that another thread won't read in the middle of writing to disk and end up with some new values and some old (which are about to be modified) ?


Thanks in advance.

[Dhruba Borthakur]

Is there a guarantee that I won't end up with data like {10, 10} {11, 1011} ? (I.e. I expect that only one set or the other stays in db and not mixed, is this assumption correct?)

Your assumption is correct.

 

all is there a guarantee that another thread won't read in the middle of writing to disk and end up with some new values and some old (which are about to be modified) ?

Yes, it is guaranteed.

The way it is implemented internally is that all the writes inside a single WriteBatch is assigned the same sequence number and is written as a single entry in the write-ahead log. This ensure that the entire write batch makes it to the DB or none at all.

Similarly, a Get/Scan call picks up all data upto a specified sequence number, and since all the individual writes inside a writebatch has the same seqno, all of them will show up in a Get call.

 

[Robert Escriva]

On Thu, Jun 30, 2016 at 03:01:03PM +0100, Dhruba Borthakur wrote:
>
> Is there a guarantee that I won't end up with data like {10, 10} {11, 1011}
> ? (I.e. I expect that only one set or the other stays in db and not mixed,
> is this assumption correct?)
>
>
> Your assumption is correct.

Not with the example code. Both write batches will be written because
they don't overlap. If there was overlap, it is guaranteed that the
keys in common will be those written by just one of the write batches.

[Ren Z]

Regarding 2) here http://stackoverflow.com/a/38125392/579026 are some thoughts why it may not be guaranteed, could you comment on that?

[sel-fish]

all the individual writes inside a writebatch has the same seqno

I'm afraid i can't agree with that as the code says :

WriteBatchInternal::SetSequence(updates, last_sequence + 1);
last_sequence += WriteBatchInternal::Count(updates);

在 2016年6月30日星期四 UTC+8下午10:01:06，dhruba写道：

[Robert Escriva]

They didn't read the code well enough.

When doing a Get (or taking a snapshot), the code calls the
LastSequence() method of the version set to get a version number. Reads
will ignore anything after this number.

Writers set this number only after making every element in a write batch
visible. This guarantees the reader will atomically see all of the
write batch or none of it. While every element in a write batch will
not necessarily have the same sequence number, a reader will not be able
to observe a version that splits the write batch.

On Thu, Jun 30, 2016 at 08:10:43AM -0700, Ren Z wrote:
> Regarding 2) here http://stackoverflow.com/a/38125392/579026 are some thoughts
> why it may not be guaranteed, could you comment on that?
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "leveldb" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to leveldb+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[sel-fish]

yes, @Robert Escriva is right, i didn't read the code well enough. 

i fix my answer and thanks for the sharing.

在 2016年6月30日星期四 UTC+8下午11:50:35，Robert Escriva写道：

[Mauricio Fernández]

Does that hold on system crash?
I seem to remember that LevelDB tried to recover incomplete log records on DB
open.

--
Mauricio Fernández