Can anyone tell me what the OrientDB concurrent access policy looks like?
And will this logical flow still work when multiple threads are running
through this logic at the same time? Is there a clean and bullet-proof way
to guarantee that I will not get a deadlock trying to:
1. Create vertices?
2. Resolve resolve vertex Id keys to RIDs?
3. Test for existence of vertices and edges by name/Id?
4. Create edges?
Doing this in a function inside the database seemed like a good idea, and
when it runs it is pretty fast for all that it does, but it seems to be
colliding with itself sometimes, and I'm concerned about it scaling to
multiple threads. I am feeding the functions via Mule.
*If there is a better way, I would like very much to know it.*
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 <[email protected]> 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
>>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "OrientDB" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/orient-database/MMh_SxSdYKQ/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> 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.
