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
>
