Hi Ted

Agreed - I am not sure whether we (Atlas) are being fully diligent with regard to always closing off every tx yet - but I can check that.

Even outside of the Atlas (embedded) scenario, the documentation example in 10.3 caught my eye because it may throw an exception due to the name already being taken, rather than a failure during commit (which as you correctly point out would instigate an internal rollback). So it seems that we would leave the tx open unless the catch block were to issue a rollback. I know it's only an example, but it could be used as a template/best practice.

Best regards,
 Graham

Graham Wallis
IBM Analytics Emerging Technology Center
Internet: graham...@...        
IBM Laboratories, Hursley Park, Hursley, Hampshire SO21 2JN
Tel: +44-1962-815356    Tie: 7-245356




From:        Ted Wilmes <twi...@...>
To:        JanusGraph developers <janusgr...@...>
Date:        19/01/2018 02:17
Subject:        Re: Documentation question: Section 10.3 Transaction Failures
Sent by:        janusgr...@...

---

Sorry, read through the snippet too quick and I think I see what you're getting at. If you are using Janus embedded like Atlas is, you do need to be careful with transactions, not only defining clear boundaries for rollbacks, but also to startup a new transaction, which in many cases, I just use a rollback. For example, say you're accepting remote requests, each worker thread has a Janus transaction associated with it, even if you're not writing data in a thread and committing, the tx cache will be populated as the tx is left open so if you don't clear it out on, say, each user request, the chance of them seeing stale, cached data increases. When you access Janus remotely via Gremlin server, unless you run in session mode, all of this is handled by Gremlin server so your calls are all auto-committed and if an error occurs they're rolled back.

--Ted

On Thursday, January 18, 2018 at 8:03:53 PM UTC-6, Ted Wilmes wrote:
Hi Graham,
If the exception is thrown during the commit, Janus will automatically role the transaction back. You can see how it's handled internally here.

--Ted

On Monday, January 15, 2018 at 4:39:51 AM UTC-6, graham...@... wrote:

In Section 10.3 (Transaction Failures) should there be an explicit rollback added to the catch block?

try {
    if (g.V().has("name", name).iterator().hasNext())
        throw new IllegalArgumentException("Username already taken: " + name)
    user = graph.addVertex()
    user.property("name", name)
    graph.tx().commit()
} catch (Exception e) {
    //Recover, retry, or return error message
    println(e.getMessage())
    graph.tx().rollback()   // <------- Added line 
}

This particular try block traversal is benign, but it seems like it would be good practice to ensure the transaction is rolled back.

Thanks 
  Graham

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/AC_4AGypd1s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/e88abe1e-2d91-48cc-8d17-c49299b1ce82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU