hibernate-devel

Re: [Hibernate-devel] Transaction changes checked in

[Gavin_King/Cirrus%<CI...@ci...>]

> I've checked in an initial, quite minimal version of the transaction
> changes.  This message is mainly for Gavin's benefit, but if anyone
> else wants to follow along or comment, the gory details follow.

Cool! Looks all good. Two small changes I'd like:

(1) The no-argument form of Hibernate.buildSessionFactory() has the
following comment:

"Create a new TransactionFactory with the default (JDBC) transaction
handling strategy."

I would prefer (to be consistent with other stuff) that the no-argument
form uses System properties to determine the transaction_strategy.

(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().

I will make these changes tonight if you don't beat me to it.

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.

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 haven't yet implemented JTATransaction or CMTTransaction, although
> obviously they ought to be pretty simple (if not completely empty).

They need to flush the session and call setRollbackOnly() on the
UserTransaction/EJBContext. JTATransaction needs to do a JNDI lookup to
grap the UserTransaction, so i suppose it will need the existing
hibernate.jndi.url and hibernate.jndi.class properties.

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....

Thanks for the new code

Gavin

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 ;)

RE: [Hibernate-devel] Transaction changes checked in

[Gavin_King/Cirrus%<CI...@ci...>]

> * The mechanism for choosing an xxxTransaction class is very simple

Since different Transaction subclasses probably need their own factory
subclass (as we discussed in previous posts), we probably need to have the
property select the factory subclass, not the transaction subclass.
Otherwise its all good.

> * Should buildTransactionFactory() be named createTransactionFactory?

dont care too much. was sticking to "build" to indicate things that are
potentially time-consuming (ie. it suggests "only do this once"). Hence if
buildTransactionFactory might need to cache a JNDI context, it is
appropriately named. (Also notice it has a no-arg form and a Properties
form which matches buildSessionFactory.) So build seems sensible.

> * Saving the best till last (you're going to hate me): I still think
> there's a good case for putting the beginTransaction() factory method
> on the Session interface (but leaving the rest of the external design
> the same).

Yeah, go ahead - that sounds good.

RE: [Hibernate-devel] Transaction changes checked in

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

I've checked in the transaction changes previously discussed.

The major changes are that the hibernate.transaction_strategy property is
now used to select an appropriate TransactionFactory; and that
beginTransaction was added to the Session interface.

A summary of the code changes:

cirrus.hibernate:
* Hibernate.java - removed buildTransactionFactory (no longer needed,
afaict)
* Session.java - added beginTransaction to Session interface
* RelationalDatabaseSession.java - added beginTransaction method
* RelationalDatabaseSessionFactory.java - added transactionFactory variable
and private buildTransactionFactory method.

cirrus.hibernate.transaction:
TransactionFactoryImpl changed to JDBCTransactionFactory
...plus necessary refactoring.

I have yet to do any significant Javadocs, but I'll get to that shortly.

Anton

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