Hi, Luca,
I pulled and built the "develop" branch from GitHub, and then re-ran my
test. Same result. I have one specific record that will lock every time on
update. Initial insert works fine (using the "UPDATE Class CONTENT { }
UPSERT WHERE Id = 'xxx' " sql command syntax).
I wonder if it could be an issue involving updates across clusters, since
the structure of the data is such that class "Base" extends V, and
"Account" extends "Base". Base is the class (and therefore the cluster)
that contains the Id field, and it is the base class's Id field that is
indexed using the unique Hash index. Any chance there could be a collision
in coordination across clusters/indexes in that scenario?
Thanks,
Patrick
On Saturday, April 4, 2015 at 8:11:33 AM UTC-6, Lvc@ wrote:
>
> 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]
> <javascript:>> 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] <javascript:>.
>> 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.
