> I would prefer (to be consistent with other stuff) that the no-argument > form uses System properties to determine the transaction_strategy.
Will do. Actually that's a little broken right now anyway - I tried something that didn't work (not very familiar with the property stuff). > (2) JDBCTransaction should only toggle autocommit at begin() and commit() > if Connection.getAutoCommit() returns false when we begin() the > transaction. Also, we need to toggle autocommit back to false after > rollback(). Eep, I meant to go back and look at that - like I said, it's minimal. I mainly wanted to check in a starting point so we could remain in sync on what it should look like. > I will make these changes tonight if you don't beat me to it. You'll probably beat me, then - it's 1 am here and I'm almost off to bed. > Anton, if you get a chance, would you please Javadoc the two new API > classes, Transaction and TransactionFactory, along the lines of what we > already have for Session and SessionFactory. Will do. I wanted to make sure the API was settled before starting any serious docs. It may take me a couple days to do the docs, since I'm working towards a business deadline at the moment. > I will add a test case for the new Transaction API to the FooBarTests as > soon as I get a chance. > > We also need to document this stuff in doc/tutorial.aft. I > suppose I should > do that bit. I'm happy to take a stab at this too, but can't promise a timeline right this minute. I'd suggest that you focus on your highest priority stuff and I'll see if I can beat you to any of this. > My reason for including a TransactionFactory interface was so a > JTATransactionFactory could cache the JNDI context. (We don't want to > obtain the JNDI Context every time we start a transaction.) At the moment > you have only one TransactionFactory implementation and I'm not quite sure > how we should handle multiple TransactionFactory implementations in an > extensible way. So that gives us something to think about.... The buildTransactionFactory method could pick a TransactionFactory implementation, based on property settings. If the actual TransactionFactory interface needs to change depending on which implementation is picked, the user could downcast the returned interface, I guess... Are there any other issues? > P.S. I am breaking my promise not to add any new features + am > implementing lifecycle objects for 1.0. (The #1 most popular > outstanding feature request.) This is the last thing, i promise ;) Suuuuure!!! Anton _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
