Date
1 - 2 of 2
DistributedStoreManager sleepAfterWrite
|
Melvin Ross <melvi...@...>
I've been going through the Janus source and noticed that the Hbase and Cassandra backends both call sleepAfterWrite after sending the write request to the underlying backend. What I can't seem to comprehend is why. It doesn't have a JavaDoc block, but this seems like a bug due to the fact that the function immediately before it had a javadoc, but its commented out. https://github.com/JanusGraph/janusgraph/blob/b00bfe7a4a4f3d936bd219cfe9858dbe18b5874d/janusgraph-core/src/main/java/org/janusgraph/diskstorage/common/DistributedStoreManager.java#L224 My original thought was that it was to ensure that we don't create another transaction on the same thread that reuses the the exact same timestamp. However, at least in the CQL cassandra implementation, it's already blocking for the write result. https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-cql/src/main/java/org/janusgraph/diskstorage/cql/CQLStoreManager.java#L413 But a few lines lower at 419, sleepAfterWrite is called. The thread's already sent the statements to Cassandra, and gotten a response at that point. Why is it sleeping? I'm hoping the rest of you can shed some light onto this and tell me what I'm missing. The astyanax, embedded and thrift implementations seem to be synchronous as well, but also sleep. https://github.com/JanusGraph/janusgraph/blob/52975f940e67a8e1c303694b0d5f9604bbb9af22/janusgraph-cassandra/src/main/java/org/janusgraph/diskstorage/cassandra/embedded/CassandraEmbeddedStoreManager.java#L211 https://github.com/JanusGraph/janusgraph/blob/0b1b8237c5d4e8a41bde5f9f3b4cc6c66ab698bc/janusgraph-cassandra/src/main/java/org/janusgraph/diskstorage/cassandra/astyanax/AstyanaxStoreManager.java#L411 https://github.com/JanusGraph/janusgraph/blob/52975f940e67a8e1c303694b0d5f9604bbb9af22/janusgraph-cassandra/src/main/java/org/janusgraph/diskstorage/cassandra/thrift/CassandraThriftStoreManager.java#L304 -Melvin |
|
|
|
Jason Plurad <plu...@...>
The javadoc on MaskedTimestamp seems to describe the reasoning: > Helper class to create the deletion and addition timestamps for a particular transaction. It needs to be ensured that the deletion time is prior to the addition time since some storage backends use the time to resolve conflicts. On Tuesday, February 6, 2018 at 5:20:07 PM UTC-5, Melvin Ross wrote:
|
|
|