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 > > > > > >
