RE: [Hibernate-devel] Transaction changes checked in

[Anton v. S. <an...@ap...>]

> 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