Date
1 - 6 of 6
Documentation question: Section 10.3 Transaction Failures
|
graham...@...
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 |
|
|
|
Ted Wilmes <twi...@...>
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:
|
|
|
|
Ted Wilmes <twi...@...>
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:
|
|
|
|
Graham Wallis <graham...@...>
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 <tw...@...> To: JanusGraph developers <janus...@...> 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 -- |
|
|
|
Ted Wilmes <twi...@...>
I realized I went on and never really addressed your point. I do think you're right, the docs could be improved there. If you could create a new issue with some bullets describing the scenarios, that would be much appreciated and any doc contributions would be an added bonus.
Thanks, On Fri, Jan 19, 2018, 4:04 AM Graham Wallis <graham...@...> wrote: Hi Ted |
|
|
|
Lighter <yangch...@...>
Hi, Ted. I checked the internal implementation about roll back. if I use HBase as backend for below snippet, if "name" is also an index. the transaction will update two rows. if the row related index update write succeed, while the row related data write fail and throw exception from backend. what's the behavior of roll back, will it roll back the row that has been succeed written to backend storage? try { if (g.V().has("name", name).iterator().hasNext()) throw new IllegalArgumentException(" 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 } On Friday, January 19, 2018 at 10:03:53 AM UTC+8, Ted Wilmes wrote:
|
|
|