1. Janusgraph-Dev
  2. Messages

Re: 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:

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
Join janusgraph-dev@lists.lfaidata.foundation to automatically receive all group messages.