Hi Paul, sorry for late response.

Are you sure that thread 2 is using the same transaction instance? How do
you go about doing that btw, the only way is to get a hold of the low level
TransactionManager and do suspend/resume of that transaction. It might very
well be that you only think that both threads are sharing the same
transaction, but in reality uses separate transactions. That would explain
why thread 2 sees the created node (it's actually visible in the cache even
before committed), but not its properties.

Could you perhaps supply a test case that triggers it?

2011/7/25 Paul A. Jackson <paul.jack...@pb.com>

> I encounter an error when attempting the support multiple threads.
>
> I have a graph manager singleton that controls access to a graph and
> handles the batching of transactions (committing them only after a set
> number of operations). Multiple threads can perform read and write
> operations "concurrently", but the graph manager protect concurrent access
> thought the use of read/write locks. What I am finding is that a while
> thread can see a node that was created by another transaction before the
> transaction completes, it is not able to see the properties that were
> written to it.
>
> The step that are followed are:
> Thread 1:
>   Create a node
>   Write a property (called _stp_type) to the node
>   Save the node's ID to a map of ID's by _stp_id (yet another node
> property)
>   (the transaction is NOT committed)
> Thread 2:
>   (using the same transaction instance, possibly created by another thread)
>   Look in the map for the ID of a node with a given _stp_id
>   Get the node from the graph by ID (graph.getNodeById(id))
>   Get the _stp_type of that node (graph.getProperty("_stp_type"))
>
> Caused by: org.neo4j.graphdb.NotFoundException: _stp_type property not
> found for NodeImpl#4.
>                 at
> org.neo4j.kernel.impl.core.Primitive.newPropertyNotFoundException(Primitive.java:172)
>                 at
> org.neo4j.kernel.impl.core.Primitive.getProperty(Primitive.java:167)
>                 at
> org.neo4j.kernel.impl.core.NodeProxy.getProperty(NodeProxy.java:145)
>                 at com.g1.dcg.graph.neo4j.NeoNode.<init>(NeoNode.java:26)
>                 at
> com.g1.dcg.graph.neo4j.NeoGraph.toDcgNode(NeoGraph.java:818)
>                 at
> com.g1.dcg.graph.neo4j.NeoGraph.getNode(NeoGraph.java:1029)
>                 at
> com.g1.dcg.graph.neo4j.NeoGraphAutoTx.getNode(NeoGraphAutoTx.java:198)
>                 at
> com.g1.component.graph.WriteToGraphStage.execute(WriteToGraphStage.java:93)
>                 ... 7 more
>
> I am perfectly willing to accept that what I am doing should not work; I'm
> just a little thrown by the fact the I can see the node by not the
> properties.
>
> Wondering if it is a bug or an invalid use case.
>
> Also, if the proper approach is for each thread to create its own
> transaction, then am I correct to assume that uncommitted changes in one
> thread will not be visible to the other? Is it then the case that the only
> way for two threads to be consistent is to ensure that one thread commits
> before any other starts its own transaction?
>
> Thanks.
>
> Paul Jackson, Principal Software Engineer
> Pitney Bowes Business Insight
> 4200 Parliament Place | Suite 600 | Lanham, MD  20706-1844  USA
> O: 301.918.0850 | M: 703.862.0120 | www.pb.com
> paul.jack...@pb.com
>
> Every connection is a new opportunityT
>
>
>
> Please consider the environment before printing or forwarding this email.
> If you do print this email, please recycle the paper.
>
> This email message may contain confidential, proprietary and/or privileged
> information. It is intended only for the use of the intended recipient(s).
> If you have received it in error, please immediately advise the sender by
> reply email and then delete this email message. Any disclosure, copying,
> distribution or use of the information contained in this email message to or
> by anyone other than the intended recipient is strictly prohibited. Any
> views expressed in this message are those of the individual sender, except
> where the sender specifically states them to be the views of the Company.
> _______________________________________________
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to