I put back the class hierarchy that had been in place previously, and the
apparent deadlock behavior returned. Here is the class structure:
CREATE CLASS Base EXTENDS V ABSTRACT
CREATE Property Base.Id STRING
CREATE Property Base.DateCreated DATETIME
CREATE Property Base.DateModified DATETIME
CREATE INDEX Id ON Base (Id collate ci) UNIQUE_HASH_INDEX METADATA
{ignoreNullValues
: false}
CREATE CLASS BaseMaster EXTENDS Base ABSTRACT
CREATE Property BaseMaster.Name STRING
CREATE Property BaseMaster.Code STRING
CREATE CLASS Account EXTENDS BaseMaster
With the classes created and the index in place, I begin inserting data
using HTTP to call a javascript function to actually insert the record:
http://localhost:2480/function/Demo/loadData_Account/{ "@class":"Account"
, "Id":"11111111-5022-e411-8534-00155d016d32" ,
"Timestamp":"13129987427877781504" ,
"Company":"22222222-4c22-e411-8534-00155d016d32" , "Code":"012345" ,
"Name":"Some Name" , "Type":"1" , "SubsidiaryType":"0" ,
"PostingType":"0" , "Status":"0" }
The javascript function generates and calls the SQL Command to perform an
UPSERT:
UPDATE Account CONTENT { "@class":"Account" , "Id":
"11111111-5022-e411-8534-00155d016d32" , "Timestamp":
"13129987427877781504" , "Company":"22222222-4c22-e411-8534-00155d016d32"
, "Code":"012345" , "Name":"Some Name" , "Type":"1" ,
"SubsidiaryType":"0" , "PostingType":"0" , "Status":"0" }
UPSERT WHERE Id = "11111111-5022-e411-8534-00155d016d32"
I have 100 sample records that I use for testing. When the Id does not
exist and the operation resolves to an INSERT, then everything is fine.
When the Id does exist and the operation resolves to an UPDATE, that is
when I see the problem.
Clearly there is something about the way clusters work at the physical
storage level that I don't understand. Could the problem be that I created
properties and an index on an ABSTRACT class?
Any insights are appreciated.
Patrick
On Tuesday, April 14, 2015 at 11:01:35 PM UTC-6, Patrick Hoeffel wrote:
>
> 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.
