The way I see it is that Transaction is a handle to a resource and
therefore allowing it to be Closeable is OK.
I would advocate that the close method is not configurable and is simply
an alias for rollback.
Bryn
On 14/08/15 15:25, Stephen Mallette 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
