Update: I don't know if this necessarily "proves" anything, but I removed
the inheritance from my Account class so that Account inherits directly
from V. I added an Id property (type STRING) directly on the Account class
and then created an index (UNIQUE_HASH_INDEX, SBTREE) directly on Account
instead of on the superclass.
With these changes in place, I am no longer seeing the phenomenon that
looked like a deadlock. This is not an ideal solution, but it is *a*
solution, and I'll definitely take it for now.
Patrick
PS - the "develop" branch that I pulled and built was a 2.1 snapshot branch.
On Tuesday, April 14, 2015 at 1:49:23 PM UTC-6, Patrick Hoeffel wrote:
>
> 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]> 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.
