Some points which I want to mention about my new code:
* The mechanism for choosing an xxxTransaction class is very simple: it
reads a property called hibernate.transaction_strategy, which has a default
value of "JDBC"; it appends the string "Transaction" to the result, and
tries to load a class with that name, from the cirrus.hibernate.transaction
package. By default, it will therefore try to load the JDBCTransaction
class. The default strategy (JDBC) and classname base (Transaction) are
hardcoded in the TransactionFactoryImpl class. This could easily be made
more flexible, but I don't think it's essential at this stage. Also, making
the default strategy a property seemed kind of pointless. It might make
more sense for the classname base and package name, but I didn't want to
madly start adding unnecessary properties, especially if the class selection
mechanism changes.
* Should buildTransactionFactory() be named createTransactionFactory? I
don't really care, just wanted to mention it since both were discussed at
one point. Better yet, see following point.
* 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). The
justification for this:
o beginTransaction() currently needs to be passed a Session object, because
of the close association between the two classes.
o Within Hibernate, it won't really be meaningful to have a Transaction
without a Session (although a Session without a Transaction is OK).
o It would eliminate the need for the user to explicitly create a
TransactionFactory, and make it accessible throughout the application, in
addition to the SessionFactory. The interface needed by the user is
simplified.
o It makes sense implementation-wise, and doesn't lose any needed
flexibility. I would probably keep the existing classes, to maintain clear
design separation, but have SessionFactory maintain an internal reference to
a TransactionFactory. RelationalDatabaseSession would then implement
beginTransaction() using something like:
return factory.getTransactionFactory().createTransaction(this);
o Support for other TransactionFactories, like JTATransactionFactory, could
still be handled in whatever way we decide, as long as it's driven by
properties (the ones passed to buildSessionFactory or the default
properties), i.e. as long as there's no reason for the user to interact
directly with the creation of the TransactionFactory.
With this change, the client idiom would become:
// no longer needed:
// TransactionFactory tf = Hibernate.buildTransactionFactory();
Session s = sf.openSession();
Transaction t = s.beginTransaction(); // was tf.beginTransaction(s)
try {
Foo foo = s.load(fooid);
foo.setName("FOO");
t.commit();
}
catch (Exception e) {
t.rollback();
}
finally {
s.close();
}
My fingers are itching... ;)
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
