On Fri, Mar 30, 2012 at 8:56 AM, Brock Noland <[email protected]> wrote: > I have been thinking about Channel.getTransaction and > BasicTransactionSemantics. In the case of an error occurring, I think > users would expect close to throw away the current transaction and > start fresh. Similar to a JDBC object or file, most code catches and > logs the checked exception the close might throw. > > However, in our close check the state of the current transaction and > throw a runtime exception if it's in the wrong state, as such it > cannot be closed. Additionally, Channel.getTransaction will return the > same transaction over and over again if it's not closed. > > https://github.com/apache/flume/blob/trunk/flume-ng-core/src/main/java/org/apache/flume/channel/BasicChannelSemantics.java#L104 > https://github.com/apache/flume/blob/trunk/flume-ng-core/src/main/java/org/apache/flume/channel/BasicTransactionSemantics.java#L176 > > As such, in a source or sink, the only way to "start afresh" is to > have a method as follows: > > try { tran.begin()} } catch(Exception e) {} > try { tran.rollback()} } catch(Exception e) {} > try { tran.close()} } catch(Exception e) {} > > Thoughts?
In my opinion, tx.close() should be a safe operation that never throws any exception and cleans up the transaction no matter what. If it so happens that the system is in an inconsistent state, the other methods should throw exceptions to indicate that. The reason for this is that without a safe tx.close() we can never recover from a failed state as you have pointed out. Thanks, Arvind > > Brock > > -- > Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
