Rob, can you explain the notion of "concurrent transactions". Are transactions not always concurrent? Are you proposing (in option 2) to explicitly introduce the notion of a connection and tie transactions to them instead of ThreadLocal?
thanks Simon From: Rob Vesse <[email protected]> To: "[email protected]" <[email protected]> Date: 10/24/2012 02:24 PM Subject: Re: Transaction APIs Hmmm this is a tricky one ------ To summarize that epic thread for those not inclined to read it the proposed solutions boils down to two options: Option 1 - Single Global Transaction with auto-commit when not explicitly used Basically transactional classes provide boolean begin(), boolean commit() and boolean rollback() methods. Boolean return indicates whether the operation succeeded If these methods are used any modification operation occurs inside a transaction and is only committed when commit() gets called. If the methods aren't used any update operation is treated as a single auto-committed transaction Option 2 - Arbitrary Transactions Transactional classes provided Transaction begin() method, Transaction class provides commit() and rollback() methods Operations wishing to use transactions must explicitly pass around Transaction objects, optionally operations may still be auto-committed and these will internally generate their own Transaction object by calling begin() ------ Both approaches have pros and cons: Option 1 + Simpler to implement + API is not transaction-centric - No notion of concurrent transactions Option 2 + More complex to implement + Allows concurrent transactions - Requires the API to be transaction-centric since many operations will need to know what transaction they occur in - Requires consideration of transaction isolation ------- As I understand it TDB currently uses a hybrid of the two with per-thread transactions using ThreadLocal's? Transitioning to something closer to Option 2 would probably be ideal as having a more Transaction-centric API would force users to be more explicit in how they use transactions and perhaps avoid some of the types of bugs we currently see where users leverage transactions in their current form incorrectly The downside is that it would be a fairly substantial API change necessitating a major version bump and imposing a lot of burden on users to upgrade their code. Rob On 10/12/12 11:39 AM, "Andy Seaborne" <[email protected]> wrote: >FYI > >If you're interested in API design then the discussion on the >sesame-general list on transaction API changes for the next version >(2.7.0) might be of interest: > >http://sourceforge.net/mailarchive/message.php?msg_id=29949973 > >So .. what should it look like in Jena (long term)? > > Andy
