Date
1 - 2 of 2
Documentation question: Section 10.6 Nested Transactions
|
Jason Plurad <plu...@...>
Let's say Transaction A from the example begins first and sets v2 uniqueName=foo. Transaction A takes a long time to "do many other things", so it is not committed yet. Transaction B then begins and creates a v3 vertex with uniqueName=foo. v3 is able to set uniqueName=foo because it is isolated from Transaction A and has no idea that v2 wants to set uniqueName=foo. Transaction B is committed first. When Transaction A calls graph.tx().commit(), it will throw an exception because uniqueName=foo on v2 conflicts with v3. Does that make sense? We could add more words to the doc to clarify if necessary. On Monday, January 15, 2018 at 5:45:11 AM UTC-5, graham_wallis wrote:
|
|
|
|
graham...@...
Hi - in section 10.6 it's not clear (to me - apologies if I'm being thick) why the nested transaction would fail. The example is: v1 = graph.addVertex() //Do many other things v2 = graph.addVertex() v2.property("uniqueName", "foo") v1.addEdge("related", v2) //Do many other things graph.tx().commit() // This long-running tx might fail due to contention on its uniqueName lock but presumably vertex v2 is only visible in the scope of the local transaction (that will have auto-started on the addition of vertex v1). Why would adding any property to v2 run into lock contention? I would have expected that no other thread will be able to 'see' v2 until we have committed the local transaction? Apologies if this is obvious to others, I was worried that we might need to update the doc - hence asking this on the dev list rather than the users list. Thanks Graham |
|
|