On Fri, Feb 7, 2014 at 3:42 PM, Emmanuel Lécharny <[email protected]>wrote:
> Hi, > > there are two things to consider in order to support transactions : > > - we could have automatique transaction per operation (ie, we don't have > to start a transaction before issuing an operation) > - we can also create a transaction explicitely, and use it across more > than one operation. > > We want to support both cases. > > +1 , IMHO implicit transaction support is a MUST > This is not trivial, as we want to make it as easy as possible for our > users. Typically, how should an operation know which kind of transaction > it is dealing with ? Let's have a look at such an operation : > > insert : > // check if we are already into a txn > if (in transaction) (1) > then > process operation > else > start transaction (2) > process operation > commit operation > > so far, it seems ok, but what if another thread has started a > transaction *just* after the test (1) and before (2) ? This is complicated. > > hmmm, how about using ThreadLocal, and not sure we need to branch based on the presence of txn handle, the start transaction(2) should always give the txn handle present in ThreadLocal > One easy solution would be to pass a transaction as a parameter. If this > parameter is null, then we can start a new transaction (but again, we > will have difficulties if we have to check if this parameter is null > inside the operation, for the exact same reason thanseen before). > > At the end of teh day, it's probably better to force people to create > the transaction *before* starting an operation : > > it would be better if we can avoid this, but this is just a wish from my view > txn = begingTransaction() > insert( txn ) > txn.commit() > > That's not really beautiful, but it will be safe. I'm also trying to > think about other options... > -- Kiran Ayyagari http://keydap.com
