[jira] [Commented] (TINKERPOP3-826) OneToManyBarrierStrategy

["Matt Frantz (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP3-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14726356#comment-14726356 ] 

Matt Frantz commented on TINKERPOP3-826:
----------------------------------------

Seems like this type of strategy could also be useful for a vendor that wants to allow concurrent execution of various branches of a single OLTP traversal.  Any time there is a one-to-many split, the resulting traversals could be submitted to a work queue, and then "restarted" in a worker thread or process (possibly after being serialized and transmitted to another computation node).

> OneToManyBarrierStrategy
> ------------------------
>
>                 Key: TINKERPOP3-826
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-826
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: process
>            Reporter: Marko A. Rodriguez
>            Assignee: Marko A. Rodriguez
>             Fix For: 3.1.0-incubating
>
>
> Currently, for doing energy diffusions with Gremlin sacks, you do this:
> {code}
> gremlin> g.withSack(1.0).V(1).local(out('knows').barrier(normSack)).sack()
> ==>0.5
> ==>0.5
> {code}
> Why are we doing this? Because {{out('knows')}} is one-to-many and thus, after we split the traversers, we need to renormalize their sacks so you always have a constant total energy (i.e. 1.0).
> However, starts to look ugly if the traversal is complex. Perhaps we have {{OneToManyBarrierStrategy}} that can be activated which simply wraps all {{flatMaps}} into a {{local(....barrier(consumer))}}. If that strategy is activated, then the above diffusion would look like this:
> {code}
> gremlin> g.withSack(1.0).V(1).out('knows').sack()
> ==>0.5
> ==>0.5
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)