Right now, the answer is not consistent and it is not enforced at the TinkerPop level. It's up to users to properly maintain their transactions - same as TP2. If you're asking what it should be, I'd guess we'd want the safe route and expect rollback.
On Fri, Aug 14, 2015 at 12:03 PM, Matt Frantz <[email protected]> wrote: > OK, so it won't go out of scope, but what is the expected behavior if > neither commit nor rollback are called? > > On Fri, Aug 14, 2015 at 8:48 AM, Stephen Mallette <[email protected]> > wrote: > > > It would be weird for Transaction to go out of scope with Graph going out > > of scope, as Graph will maintain the reference to the Transaction object. > > Are you asking what happens to a workload that is in the midst of retry > in > > one thread, where another thread closes the graph? if so, the answer is > > going to be dependent on the Graph implementation. I bet Neo4j would > stall > > the thread trying to close in the hopes that the other thread finishes > what > > it was up to and properly closes the transaction. > > > > On Fri, Aug 14, 2015 at 11:32 AM, Matt Frantz < > [email protected]> > > wrote: > > > > > Should we decompose the AutoCloseable behavior into a separate class > that > > > has the behavior Bryn describes? > > > > > > try (TransactionRollbacker r = new TransactionRollbacker(graph.tx()) { > > > ... > > > r.commit(); > > > } > > > > > > What is the default garbage collection behavior of a Transaction that > has > > > not been either committed or rollbacked (rolled back)? That is, if I > > have > > > called Transaction.submit, what are the guarantees on the Workload if > the > > > Transaction goes out of scope? > > > > > > On Fri, Aug 14, 2015 at 7:25 AM, Stephen Mallette < > [email protected]> > > > wrote: > > > > > > > I just thought I'd post this here to the dev list directly to make > sure > > > it > > > > was noticed. Matthias had brought up some issues with > > > > Graph/Transaction.close() just before GA was released. I created > this > > > > issue for it to fix it in 3.0.1: > > > > > > > > https://issues.apache.org/jira/browse/TINKERPOP3-764 > > > > > > > > Basically, there were some mixed semantics between Graph.close() and > > > > Transaction.close() that didn't jive up well in the javadoc or the > > tests. > > > > I straightened those out. As I thought about that, I realized that > > > > Transaction implemented Closeable. I thought it kinda weird because > > > > Transaction isn't really a "transaction object" to be passed around - > > > it's > > > > just a class to hold the transaction related methods. Making it > > > Closeable > > > > seemed wrong in that sense. So as the comments showed, I deprecated > > > > Transaction.close() and related methods/enum with the thought that at > > > some > > > > point we would remove the Closeable interface, which i created an > issue > > > > for: > > > > > > > > https://issues.apache.org/jira/browse/TINKERPOP3-805 > > > > > > > > Bryn quickly commented that he would like to do AutoCloseable so that > > he > > > > could do this: > > > > > > > > try (Transaction tx = graph.tx()) { > > > > //Do stuff > > > > tx.commit(); > > > > } > > > > > > > > where the default close behavior would be ROLLBACK. I'd just have to > > > > remove the deprecation I just added, but that's not a big deal. Does > > > > anyone else want it that way or have other thoughts on this? Is > that a > > > > usage pattern we want to encourage (recalling that Transaction is > not a > > > > "transaction object")? > > > > > > > > Thanks > > > > > > > > > >
