I forgot to point out that I'm using the REST mode, more relevant to a 
potential async behaviour.., just for the info.

On Tuesday, August 12, 2014 12:48:08 PM UTC+2, Michael Azerhad wrote:
>
> I didn't try without SDN ..
> I'm reading the actual code of SDN to detect something that could be 
> linked but I'm only seeing pure synchronous call. 
> Will try now to make it without SDN at all :)
>
> Is it really "absurd" to think of an async behaviour of transaction 
> commit? Or is it quite possible?   
>
>
> On Tuesday, August 12, 2014 12:39:01 PM UTC+2, Michael Hunger wrote:
>>
>> Would you be able to reproduce it without SDN, just plain neo and 
>> ExecutionEngine?
>>
>> Sent from mobile device
>>
>> Am 12.08.2014 um 12:36 schrieb Michael Azerhad <[email protected]>:
>>
>> Hi,
>>
>> I'm using SDN 3.1.2 with Neo4j 2.1.2.
>>
>> I have this (simple) Akka code (a worker actor retrieving new events in a 
>> kind of loop to consume them): 
>>
>> def receive = {
>>     case RetrieveNewEvents =>
>>       val tx = graphDatabaseService.beginTx()  //starts transaction
>>       try {
>>         val newEvents = eventRepository.findNewEvents(
>> EventBatchSizeProperty)  //involving @Query("MATCH (e:Event:New) RETURN 
>> e ORDER BY e.occurredOn LIMIT {0}")
>>         newEvents.foreach {
>>           event => {
>>             log.info("sending event: " + event.id + " to eventStream")
>>             context.system.eventStream.publish(event)     // sent event 
>> to consumers - no importance for the issue
>>             log.info("event sent to actors to be consumed !")
>>             eventRepository.flagAsConsumed(event.id)    // involving 
>> @Query("MATCH (e:Event {_id: {0}}) REMOVE e:New SET e:Consumed return e")
>>             log.info("event: " + event.id + " flagged as consumed !")
>>           }
>>         }
>>         tx.success()  // commit the transaction
>>       }
>>       catch {
>>         case e: Throwable => log.info(e.getMessage)
>>       }
>>       finally {
>>         tx.close()   //close the transation 
>>         system.scheduler.scheduleOnce(EventListenerScheduleProperty 
>> seconds, self, RetrieveNewEvents)  // loop again by sending a 
>> RetrieveNewEvents after 1 second
>>       }
>>   }
>>
>> I noticed that for some events, I retrieved them more that once (written 
>> in my logs)... as if the transaction was not commited, meaning that the 
>> label was not set to CONSUMED yet. 
>> Obviously, if was not set to CONSUMED before the next loop, it would be 
>> retrieve again since still viewed as NEW. 
>>
>> My question is: 
>>
>> May it possible that tx.success() or tx.close() works...asynchronously?! 
>>  It seems absurd but it sounds to be the only explanation I guess for 
>> retrieving more than once the same event.
>> I tried to update the duration from 1 second to 3 seconds, and now the 
>> whole works without this issue.
>>
>> Is there an apparent issue in my code that I may ignore? Why timing is 
>> important here?
>>
>> Thanks a lot,
>>
>> Michael
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Neo4j" 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 
"Neo4j" 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.

Reply via email to