Is Hazelcast's split brain recovery merge operation transactional?

[Archie Cobbs]

(cross-posted from stackoverflow)

Just starting to learn about Hazelcast so apologies for any ignorance below...

Hazelcast conducts a "merge" operation after recovery from a split-brain scenario. This is described here.

I'm trying to determine if this merge operation appears as an atomic operation, from both the point of view of the merging cluster and the point of view of the cluster being merged into. This is assuming a map that is set up for two-phase commit.

It appears from the description that it is indeed transactional for the merging cluster (it says "pause" ... then "resume").

Less clear is the situation on the cluster being merged into. Are all the merged values applied in a single transaction, or is each merged value merged in a separate transaction?

Thanks.

[Enes Akar]

Values are merged in seperate transactions (seperate remote operations).

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To post to this group, send email to haze...@googlegroups.com.
Visit this group at http://groups.google.com/group/hazelcast.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/352f7283-b212-4973-a47b-d4a1c89889d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Enes Akar

Director of Engineering
Mahir İz Cad. No:35, Altunizade, İstanbul

en...@hazelcast.com 
@enesakar

[Archie Cobbs]

Thanks Enes for the quick answer.

This seems like a fairly important missing feature, at least for my proposed use case.

The reasoning is: if you are using two-phase commit it's probably because you want consistent transactions in order to guarantee some property of your data. For example, your map entries may contain a child -> parent references, and you want to ensure that no node can ever see a dangling reference where a child points to a parent but the parent does not exist (i.e,. you want referential integrity).

Under normal operation with two-phase commit, you'll get this guarantee, but if there is a split-brain and then a merge, without a single two-phase transaction for the whole merge operation, then the merge target cluster will be able to see dangling references while the merge is taking place.

I'm using referential integrity as an example; there are lots of other possible reasons to use two-phase commit.

So it would be nice if there were some way to make the merge target cluster also perform the entire merge transactionally.

I'm curious about others' opinions.

Thanks,
-Archie