On Jan 8, 2021, at 12:31 AM, HadoopMarc <bi...@...> wrote:

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:

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:

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

-- 
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 janusgra...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/be55beac-0b12-4ac3-abc5-c2eb849f5366n%40googlegroups.com.

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:

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

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