thanks. Sorry, the idea of one single global transaction was not clear to me because I would consider that kind of useless in practice. TDB/Tx today obviously allows multiple concurrent transactions but as you point out, it relies on Java threads to keep them apart. I think this is quite a reasonable approach. Even on regular databases with a more explicit connection model, using the same connection across multiple threads (in Java at least) is not recommended.
but from what you wrote below, I am not sure what kind of benefits you see in an explicit Transaction object. You allude to user bugs and misuse of the transaction API. Could you give an example? thanks Simon From: Rob Vesse <[email protected]> To: "[email protected]" <[email protected]> Date: 10/24/2012 05:34 PM Subject: Re: Transaction APIs "concurrent transactions" == "more than one transaction running" If you have Option 1 (a single global transaction) then you by definition only ever have one transaction running because there is no way to have multiple transactions. Whereas Option 2 or TDB's current transaction model does allow for multiple transactions to run at the same time (albeit TDB has the MRSW restriction) Yes Option 2 essentially proposes that we introduce a TransactionProvider interface (the notion of a connection is not generally applicable so I'm purposefully avoiding that terminology) which provides a single begin() method which provides a Transaction object. Code that is transaction aware consumes a Transaction object as one of it's arguments and then acts appropriately depending on the Transaction object it is given e.g. operates on the state of the data as represented by the given transaction, fails if the transaction was already committed/rolled back etc. Rob On 10/24/12 11:48 AM, "Simon Helsen" <[email protected]> wrote: >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 > > >
