Correct usage of unique() indexes on Titan : Question about PermanentLockingException

46 views
Skip to first unread message

bhuvanrk

unread,
Sep 2, 2016, 2:12:35 PM9/2/16
to Aurelius
I'm using Titan 1.0.0 with Cassandra backend. I created two composite indexes on Titan : 

 index1 =   mgmt.buildIndex(indexName, Vertex.class).addKey(indexPropertyKey1).addKey(indexPropertyKey2).unique()

                    .buildCompositeIndex();


 index2 =   mgmt.buildIndex(indexName, Vertex.class).addKey(indexPropertyKey1).addKey(indexPropertyKey3).unique()

                    .buildCompositeIndex();


My intent behind doing this is to ensure that there is exactly only 1 entry in the backend with Key1+Key2 composite combination. I dont want any duplicates. I want to enforce the same thing with index2. 


My understanding was that these are two different index constructs so they should not run into any conflict between each other. But I notice that when I'm trying to do a concurrent access/update on index1 and index2, I get a locking.PermanentLockingException from Titan. If access them serially I don't run into any trouble. 


Some questions I have : 


1. Is my usage of unique() correct ?

2. I'm not explicitly setting ConsistencyModifier.LOCK, so I'm assuming this is getting set by default to true by some other layer ? Does it matter one way or the other ? 

3. These are two different indexes. So their access should be mutually exclusive. Am I missing something here ? 

4. They do share one of the property keys, key1, does that matter ? 

5. How can I allow concurrent access of these two different indices ? Can I allow this explicitly ? What does it cost ?


Thanks


Here is the error in-case someone is interested : 


2016-09-01T12:17:19.29-0700 [App/0]      OUT [Z: C:] 2016-09-01 19:17:19 ERROR [pool-30-thread-1] c.t.t.g.d.StandardTitanGraph [StandardTitanGraph.java:695] Could not commit transaction [8] due to storage exception in system-commit

2016-09-01T12:17:19.29-0700 [App/0]      OUT com.thinkaurelius.titan.core.TitanException: Could not execute operation due to backend exception

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at com.thinkaurelius.titan.diskstorage.util.BackendOperation.execute(BackendOperation.java:44)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at com.thinkaurelius.titan.diskstorage.keycolumnvalue.cache.CacheTransaction.persist(CacheTransaction.java:87)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at com.thinkaurelius.titan.diskstorage.keycolumnvalue.cache.CacheTransaction.flushInternal(CacheTransaction.java:141)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at com.thinkaurelius.titan.diskstorage.keycolumnvalue.cache.CacheTransaction.commit(CacheTransaction.java:198)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at com.thinkaurelius.titan.diskstorage.BackendTransaction.commit(BackendTransaction.java:135)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at com.thinkaurelius.titan.graphdb.database.StandardTitanGraph.commit(StandardTitanGraph.java:692)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at com.thinkaurelius.titan.graphdb.transaction.StandardTitanTx.commit(StandardTitanTx.java:1352)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at com.thinkaurelius.titan.graphdb.tinkerpop.TitanBlueprintsGraph$GraphTransaction.doCommit(TitanBlueprintsGraph.java:263)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at org.apache.tinkerpop.gremlin.structure.util.AbstractTransaction.commit(AbstractTransaction.java:94)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at com.ge.predix.acs.privilege.management.dao.GraphGenericRepository.save(GraphGenericRepository.java:113)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at com.ge.predix.acs.privilege.management.dao.ResourceMigrationManager.doResourceMigration(ResourceMigrationManager.java:52)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at com.ge.predix.acs.privilege.management.dao.ResourceMigrationManager.run(ResourceMigrationManager.java:34)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

2016-09-01T12:17:19.29-0700 [App/0]      OUT    at java.lang.Thread.run(Thread.java:745)

2016-09-01T12:17:19.29-0700 [App/0]      OUT Caused by: com.thinkaurelius.titan.diskstorage.locking.PermanentLockingException: Expected value mismatch for KeyColumn [k=0x 16-165-160-114-116- 30- 97-116-116-114-105- 98-117-116-101-243, c=0x  0]: expected=[] vs actual=[120-133] (store=graphindex)





Kevin Schmidt

unread,
Sep 2, 2016, 2:47:41 PM9/2/16
to aureliu...@googlegroups.com
In my experience, trying to use unique indexes and locks to ensure uniqueness in the graph is more hassle than it is worth.  It has a huge performance hit and depending on the back-end used may not actually provide a 100% guarantee of uniqueness, so your traversal may still need to be able to handle duplicates vertices.

See https://groups.google.com/forum/#!topic/aureliusgraphs/z6kyGSlifXE/aLc2Zwb_BAAJ for the issues I had when trying to use unique indexes.

--
You received this message because you are subscribed to the Google Groups "Aurelius" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aureliusgraphs+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aureliusgraphs/f889c70b-53ea-46f4-a0fa-fbebc7300d46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

bhuvanrk

unread,
Sep 2, 2016, 5:37:19 PM9/2/16
to Aurelius
Kevin, 

Thanks for the reply. I didn't realize that there were issues with the basic "uniqueness" aspect of creating unique indices. I do seem to have a lock (set by default I guess). 

My main concern is this: These are two different indices. Why is their access globally protected (uniqueness not withstanding)? Why does it not allow for concurrent access of two different unique indices ?

I'm updating index1 on thread 1, so I should be unlocked enough to perform updates on index2 on thread2. 

I'm concerned about the performance implication of this behavior. 

To unsubscribe from this group and stop receiving emails from it, send an email to aureliusgraph...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages