Locking parent vertex while child is being updated.

[Timon Schneider]

Hi all,

I have a question about locking data through Janusgraph.

Here’s the problem:
* We have a vertex with the label “type” with several properties
* Types have one edge “hasVersion” to a vertex with a label “version”
* This version vertex has a boolean property “published”.
* The type’s properties should not be allowed to be changed if the version’s published property is true.

We’re dealing with many concurrent user’s who might changes the type’s properties and set the version’s published property to true at the same time. And we need to be sure that the type’s properties are not change once it’s published.

Is there a way to lock the version vertex once the type is being changed in a transaction? This would make sure that the type is not published by a concurrent user while it is being changed.

We’re using the following configuration. Also we’re setting all relevant elements to ConsistencyModifier.LOCK through graph.openManagement().setConsistency.
JanusGraphFactory.build()
        .set("storage.backend", "hbase")
        .set("storage.hbase.table", "testGraph")
        .set("storage.hostname", "localhost")
        .set("cache.db-cache", true)
        .set("cache.db-cache-clean-wait", 20)
        .set("cache.db-cache-time", 180000)
        .set("cache.db-cache-size", 0.5)
        .set("schema.constraints", true)
        .set("schema.default", "none")
        .open();

Thanks in advance,

Timon

[HadoopMarc]

Hi Timon

You did not state whether you studied https://docs.janusgraph.org/advanced-topics/eventual-consistency/#data-consistency and whether that would fullfil your needs.

Best wishes,    Marc

Op donderdag 7 januari 2021 om 16:18:55 UTC+1 schreef Timon Schneider:

[HadoopMarc]

Oops, that was a bit too quick, you did mention ConsistencyModifier.LOCK. The linked section reads:

" When updating an element that is guarded by a uniqueness constraint, JanusGraph uses the following protocol at the end of a transaction when calling tx.commit():

1. Acquire a lock on all elements that have a consistency constraint
2. Re-read those elements from the storage backend and verify that they match the state of the element in the current transaction prior to modification. If not, the element was concurrently modified and a PermanentLocking exception is thrown.
3. Persist the state of the transaction against the storage backend.
4. Release all locks. "
   

Your problem seems that you required locking scope is larger than what you modify in a transaction. This means you should rethink your data model (do you really need this complexity?) or maybe you have to artificially broaden the transaction scope by dropping all properties and re-adding them.

Best wishes,     Marc

Op donderdag 7 januari 2021 om 17:21:06 UTC+1 schreef HadoopMarc:

[BO XUAN LI]

Hi Timon,

If I am understanding correctly, your code logic is like this:

start_transaction();

read_vertex(type_v);

read_vertex(version_v); // type_v ——hasVersion—> version_v

if (version_v.published == true) then abort();

update_vertex(type_v);

update_vertex(version_v); // set version_v.published = true

commit();

Then I think setting ConsistencyModifier.LOCK for “published” property is sufficient. Using more locks make your transactions run slower.

I would also suggest turning cache.db-cache off. Using database level cache might lead to stale read. If everything works well, you can again try turning db-cache on and tune the configs to see if you can still make data locking work.

However, if you are changing “type” vertex and “version” vertex in different transactions, then I think you need to rethink about your data modeling, or change your application logic to make the locking work.

Best regards,

Boxuan

-- 
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/be55beac-0b12-4ac3-abc5-c2eb849f5366n%40googlegroups.com.