I believe that just affects the document API. 2.0.6 has just been released. You might try it and see if the deadlock still occurs.
Please let me know. -Colin On Tuesday, March 31, 2015 at 3:07:28 PM UTC-5, Patrick Hoeffel wrote: > > Is there any chance that I'm seeing a side effect of issue #3786 > <https://github.com/orientechnologies/orientdb/issues/3786>, which is > fixed in version 2.0.6? It *does* occur during an UPSERT, after which I am > adding one or more edges. > > The issue is described as, "*In case of concurrency, the > OConcurrentModificationException should be caught and managed properly by > applying changes on loaded record.*" > > Thanks, > > Patrick > > > > On Tuesday, March 31, 2015 at 11:16:53 AM UTC-6, Patrick Hoeffel wrote: >> >> Colin, >> >> It's only running on a single thread right now, so everything is running >> serially and synchronously. The idea is that I get a JSON data document >> from a relational database (SQL Server), and that record has a number of FK >> values as fields. >> >> 1. Insert/Update the main record >> 2. Iterate over the FK fields. For each FK: >> a. Does the destination Class exist? >> If (yes) then does the Edge class exist? >> If (yes) then does the actual vertex instance of the >> destination class exist? >> If (no) then create vertex for destination end of the edge >> I'm about to create >> Does the instance of the Edge already exist? >> If (no) then "CREATE EDGE RELATIONSHIP FROM (srcVertex) >> TO (destVertex)" >> return; >> >> The deadlock is occurring on the main record, interestingly. >> >> At first I was using a Transaction so that I could roll back the whole >> operation in the event of a failure. I changed it to use NoTx(), but it >> didn't help. >> >> I'm using an UPDATE Account CONTENTS { <json> } UPSERT WHERE Id = "xxxxx" >> as the mechanism for inserting/updating the main record. Since that >> statement only returns a count of the records modified (1), I then go back >> and immediately SELECT FROM Account WHERE Id = "xxxxx". >> >> I had the best luck when I put a graph.commit() between the UPDATE and >> the SELECT statements. >> >> Is there a better way to do this? I coded a "graph.addVertex()", but I >> would still need to pre-check for existence and then UPDATE, because I >> don't see a single-call mechanism from Java for doing that, other than the >> UPSERT. >> >> My first implementation was in a Javascript function which followed the >> same logic, but it was (still is occassionally) deadlocking too. >> >> Any/all thoughts are welcome. >> >> Thanks very much, >> >> Patrick >> >> >> On Tue, Mar 31, 2015 at 10:52 AM, Colin wrote: >> >>> Hi Patrick, >>> >>> Are you sharing the same graph db connection among your threads doing >>> the querying? >>> >>> What's your design look like for writing/reading the database? >>> >>> Thanks, >>> >>> -Colin >>> >>> Orient Technologies >>> >>> The Company behind OrientDB >>> >>> On Monday, March 30, 2015 at 3:02:39 PM UTC-5, Patrick Hoeffel wrote: >>>> >>>> >>>> <https://lh3.googleusercontent.com/-ebTSvLLuih4/VRmrhCh1nCI/AAAAAAAAQ3c/JYGQAngQ8dg/s1600/OrientDB%2BDeadlock.PNG> >>>> OrientDB 2.0.5 on Windows Server 2012, client connecting from Win 7 Pro >>>> >>>> I have a Java class that is inserting a vertex and then adding outbound >>>> edges. I'm doing queries to figure out what intermediate data needs to >>>> also >>>> be created in order for my edges to be built properly, but something is >>>> causing a deadlock, and I can only get it to clear by restarting OrientDB. >>>> Here is the stack trace from Eclipse when this happens: >>>> >>>> If anyone has seen this before, please let me know. >>>> >>>> Thanks, >>>> >>>> Patrick >>>> >>> -- >>> >>> --- >>> >> >> >> -- >> Patrick Hoeffel >> >> -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
