Hi Patrick, Please could you try the "develop" branch, or 2.1-SNAPSHOT? I know some problem with concurrency has been resolved there and before to release the 2.1-rc1 (nex week) I'd like to be sure this kind of problems are resolved.
Lvc@ On 3 April 2015 at 19:04, Patrick Hoeffel <[email protected]> wrote: > Also, upgrading to 2.0.6 does not make any difference. Still getting > deadlocks, though fewer. > > Patrick > > > > On Tuesday, March 31, 2015 at 2:07:28 PM UTC-6, 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. > -- --- 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.
