Hi,
I am doing the same for long running transactions. I suspend the
transaction, storing the transaction in a conversation context and the
resuming the it on subsequent request. The transaction commits when the
conversation ends. This is working well.
However the way I understand Neo4j transactioning this also means that
if 2 separate transactions are accesing the same object the last
transaction to commit will override the previous transaction. In a
JPA/JTA world optimistic locking would prevent this from happening.
Is my understanding correct and if so are there plans to implement
optimistic locking in Neo4j?
Thanks
Pieter
On 08/08/2011 13:40, Mattias Persson wrote:
> 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
>>
>
>
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
