[
https://issues.apache.org/jira/browse/TINKERPOP-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Hu updated TINKERPOP-3142:
------------------------------
Description:
Originally discovered from:
https://stackoverflow.com/questions/79467860/issue-with-transactions-in-local-tinkerpop-gremlin-setup
[https://groups.google.com/g/gremlin-users/c/NRwb4xy2eXs]
TinkerTransactionGraph might leave a "isDeleted" TinkerElementContainer hanging
around if a read occurs during the commit of a drop(). This leads to later
errors when trying to add that element back as it "isDeleted" leading to an
exception.
The following test can sometimes reproduce the error (it's a multithreading
issue so it doesn't always reproduce).
{code:java}
@Test
public void shouldAddThenDeleteThenAddBackInSeparateTransactions() throws
InterruptedException {
final TinkerTransactionGraph graph = TinkerTransactionGraph.open();
final GraphTraversalSource g = graph.traversal();
final GraphTraversalSource gtx = g.tx().begin();
CountDownLatch signal = new CountDownLatch(1);
gtx.addV().property(T.id, 1).next();
gtx.tx().commit();
Thread reader = new Thread(() -> {
while (signal.getCount() > 0) {
g.V().id().toList();
g.tx().commit();
}
});
reader.start();
Thread.sleep(50);
g.V(1).drop().iterate();
g.tx().commit();
Thread.sleep(50);
g.addV().property(T.id, 1).next();
g.tx().commit();
signal.countDown();
reader.join();
assertEquals(1, graph.getVertices().size());
} {code}
Should a read occur when trying to delete the vertex, the usesInTransactions is
incremented
([https://github.com/apache/tinkerpop/blob/3.7.3/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerElementContainer.java#L100])
so that it won't be deleted during the commit as its uses isn't 0
([https://github.com/apache/tinkerpop/blob/3.7.3/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerElementContainer.java#L232).]
This behavior of incrementing the use count with reads gives more consistent
reads, however, the tradeoff is that it can cause TransactionExceptions to
occur. So, it would be best if this could be resolved while keeping the read
behavior consistent.
was:
TinkerTransactionGraph might leave a "isDeleted" TinkerElementContainer hanging
around if a read occurs during the commit of a drop(). This leads to later
errors when trying to add that element back as it "isDeleted" leading to an
exception.
The following test can sometimes reproduce the error (it's a multithreading
issue so it doesn't always reproduce).
{code:java}
@Test
public void shouldAddThenDeleteThenAddBackInSeparateTransactions() throws
InterruptedException {
final TinkerTransactionGraph graph = TinkerTransactionGraph.open();
final GraphTraversalSource g = graph.traversal();
final GraphTraversalSource gtx = g.tx().begin();
CountDownLatch signal = new CountDownLatch(1);
gtx.addV().property(T.id, 1).next();
gtx.tx().commit();
Thread reader = new Thread(() -> {
while (signal.getCount() > 0) {
g.V().id().toList();
g.tx().commit();
}
});
reader.start();
Thread.sleep(50);
g.V(1).drop().iterate();
g.tx().commit();
Thread.sleep(50);
g.addV().property(T.id, 1).next();
g.tx().commit();
signal.countDown();
reader.join();
assertEquals(1, graph.getVertices().size());
} {code}
Should a read occur when trying to delete the vertex, the usesInTransactions is
incremented
(https://github.com/apache/tinkerpop/blob/3.7.3/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerElementContainer.java#L100)
so that it won't be deleted during the commit as its uses isn't 0
([https://github.com/apache/tinkerpop/blob/3.7.3/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerElementContainer.java#L232).]
This behavior of incrementing the use count with reads gives more consistent
reads, however, the tradeoff is that it can cause TransactionExceptions to
occur. So, it would be best if this could be resolved while keeping the read
behavior consistent.
> TinkerTransactionGraph doesn't remove deleted elements in threaded scenario
> ---------------------------------------------------------------------------
>
> Key: TINKERPOP-3142
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3142
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
> Affects Versions: 3.7.3
> Reporter: Ken Hu
> Priority: Major
>
> Originally discovered from:
> https://stackoverflow.com/questions/79467860/issue-with-transactions-in-local-tinkerpop-gremlin-setup
> [https://groups.google.com/g/gremlin-users/c/NRwb4xy2eXs]
>
> TinkerTransactionGraph might leave a "isDeleted" TinkerElementContainer
> hanging around if a read occurs during the commit of a drop(). This leads to
> later errors when trying to add that element back as it "isDeleted" leading
> to an exception.
> The following test can sometimes reproduce the error (it's a multithreading
> issue so it doesn't always reproduce).
>
> {code:java}
> @Test
> public void shouldAddThenDeleteThenAddBackInSeparateTransactions() throws
> InterruptedException {
> final TinkerTransactionGraph graph = TinkerTransactionGraph.open();
> final GraphTraversalSource g = graph.traversal();
> final GraphTraversalSource gtx = g.tx().begin();
> CountDownLatch signal = new CountDownLatch(1);
> gtx.addV().property(T.id, 1).next();
> gtx.tx().commit();
> Thread reader = new Thread(() -> {
> while (signal.getCount() > 0) {
> g.V().id().toList();
> g.tx().commit();
> }
> });
> reader.start();
> Thread.sleep(50);
> g.V(1).drop().iterate();
> g.tx().commit();
> Thread.sleep(50);
> g.addV().property(T.id, 1).next();
> g.tx().commit();
> signal.countDown();
> reader.join();
> assertEquals(1, graph.getVertices().size());
> } {code}
> Should a read occur when trying to delete the vertex, the usesInTransactions
> is incremented
> ([https://github.com/apache/tinkerpop/blob/3.7.3/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerElementContainer.java#L100])
> so that it won't be deleted during the commit as its uses isn't 0
> ([https://github.com/apache/tinkerpop/blob/3.7.3/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerElementContainer.java#L232).]
>
> This behavior of incrementing the use count with reads gives more consistent
> reads, however, the tradeoff is that it can cause TransactionExceptions to
> occur. So, it would be best if this could be resolved while keeping the read
> behavior consistent.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
