RE: [Hibernate-devel] Simple transaction management

[Brad C. <bra...@wo...>]

forgive me if this a brain dead question - i am just skimming all this
because i currently don't have the time right now to do it justice -
what is the general structure of code that would now be used in a CMT
environment?  i was just concerned that a commit is going to replace the
flush, which doesn't make sense (in this environment).

brad

> -----Original Message-----
> From: Gavin_King/Cirrus%CI...@ci...
> [mailto:Gavin_King/Cirrus%CI...@ci...]
> Sent: Tuesday, 21 May 2002 4:39 PM
> To: hib...@li...
> Subject: RE: [Hibernate-devel] Simple transaction management
>=20
>=20
>=20
>=20
> > I think that separating the Transaction and the Session=20
> makes perfect
> > sense at a certain level, but I'm personally interested in something
> > even more high-level (you can call it "brain-dead", if you like).  I
> > have two specific issues:
> >
> > 1.  I'm not completely comfortable with requiring that every
> > transaction include the sequence:
> >
> >    s.flush();
> >    tx.commit();
>=20
> If it helps, I'm perfectly happy if Transaction.commit() calls
> Session.flush(). I don't see anything wrong with that at all. If
> it saves a line of code, its all good. ( find() methods also call
> flush() transparently )
>=20
> > With your clean separation of Transaction & Session, though, I don't
> > think that hybrid flush/commit method belongs in either of those
> > classes, so this is where the wrapper described below would come in.
>=20
> No, it doesn't and thats why the old commit()/cancel() methods were
> problematic. There is not necessarily  a 1-1 relationship between
> transactions and sessions, so modelling them as a single object
> just doesn't fit (to me anyway).
>=20
> > 2.  More generally, I think there's a case for combining the
> > Session and Transaction functionality on a single interface, just to
> > keep the final API as simple as possible.  I think we may disagree
> > on this, but I'd like to know whether you see the problem with a
> > combined interface as having mainly to do with backwards
> > compatibility, or whether you see other disadvantages to it.
>=20
> Yeah, we disagree. I see your POV and I know why it would be nice
> and, in fact, I originally designed things that way ( with
> Session.commit() and  Session.cancel() ). However, while its a more
> convenient API for most applications, I don't feel its a correct model
> of the underlying concepts. I think it will be a hassle later on.
>=20
> > 1. Since it's only intended for use in cases where an overall
> > transaction is required, the transaction can be begun upon creation,
> > so there's no need for a separate "begin" method.
>=20
> Quite happy with that. But as I pointed out begin() isnt really
> needed with seperate transaction objects either. You can do that
> stuff in the constructor. Of course, instantiating the Transaction
> is an extra operation thats not needed in your design.
>=20
> > 2. Since it incorporates Session functionality, there's no need for
> > the developer to manage two objects, a session and a transaction.
>=20
> As I see it, this is the main advantage to your model. maintaining
> pointers to both objects _does_ make application code messier.
>=20
> > 3. It's not necessary to call both flush() and commit() on a
> > TransactionalSession.
>=20
> As above, I'm happy if Transactions flush the Session.
>=20
>=20
> > One possible downside is that this can be seen as introducing a
> > kind of dual API, which would have to be carefully dealt with in
> > documentation.
>=20
> I am soooo not keen on this. The main reasons we wanted to do all
> this in the first place were:
>=20
> 1. Abstract application code from the actual transaction mechanism
> ( and away from JDBC.setAutocommit() ).
> 2. Be easier to learn.
>=20
> It seems to me that (1) is fully satisfied by the approach of having
> seperate transaction objects. (2) is somewhat satisfied though I
> will give you that your proposed API is simpler yet.
>=20
> What I am quite certain of is this: documenting 2 different APIs and
> giving new users a choice will unsatisfy (2). Its like "well, we cant
> make up our mind on the right way to model it so we will add a whole
> bunch of extra unnecessary complexity to allow _both_ models".
>=20
> :)
>=20
> > The general way I'm looking at it, though, is that Sessions and
> > Transactions are building blocks used to create a higher level
> > layer (the "hibernate.4dummies" layer?  Count me as dummy #1 :)
>=20
> Heh, in my comment about dummies I certainly meant no disrespect
> to sensible people who prefer simpler APIs over complicated ones
> :-)
>=20
> > In a sense, TransactionalSession isn't that different from the
> > deprecated Session API, with its commit and cancel methods.
>=20
> Exactly. And people found the old API confusing.
>=20
> > > Properties props =3D new Properties();
> > > props.setProperty("hibernate.transaction_strategy", "JTA");
> > > TransactionFactory txFactory =3D
> Hibernate.createTransactionFactory(props);
>=20
> > The question would arise of whether a beginTransaction() method (or
> > createTransaction() or whatever)
>=20
> I get the impression we will all agree on beginTransaction() :)
>=20
>=20
> > > (1) I had kind of hoped to roll the stuff thats done by
> ConnectionProvider
> > > into the TransactionStrategy (ie opening, closing a JDBC
> > > connection) but it now seems to make more sense to orthogonalize
> > > these things. Does everyone else concur with that?
>=20
> > It sounds right to me.  The hand-waving summary of my imagined
> > design involves discrete, single-purpose components under the hood,
> > being combined at a high level in interfaces like Session and
> > TransactionalSession.
>=20
> quite.
>=20
> > > (2a) For swappable Transaction strategies to work,=20
> JTATransaction would
> > > need to look up the surrent transaction in JNDI. Is this=20
> always okay?
> The
> > > usual way to get the current transaction in an EJB is from the
> EJBContext.
> > > (2b) What about in a CMT bean? I guess you would just=20
> need to revert to
> > >
> > > Transaction tx =3D new ContainerTransaction(session, ejbContext);
>=20
> > My thought was that if Hibernate provides a few basic transaction
> > strategy implementations initially, they should be fairly small,
> > simple and take the most obvious approach, as you suggest. =20
> Users with
> > different requirements can tweak them, improve them, write=20
> their own,
> > or just complain.  The docs could ask for feedback about this.
>=20
> quite.
>=20
> > Sorry to be dragging this out.  We've definitely made great progress
> > - I'm just being very demanding.  In my defense, I think the more
> > effort that goes into coming up with good designs at this level, the
> > more widely useful and long-lived the result is likely to=20
> be.  But if
> > I'm taking things too far or sucking up too much bandwidth at this
> > 1.0-is-imminent stage, feel free to apply brakes.
>=20
> Your suggestions are _very_ welcome Anton. And I strongly believe that
> ideas should always be put forward as strongly-as-possible to get the
> most out of them. Clearly we have already agreed on a bunch of stuff
> that makes us all happier than before. I'm not yet 100% sure if
> TransactionalSession should be left as an exercise for the user or
> should eventually be integrated into the core API. I am 100% sure I
> don't want to make the decision now, cos I might regret it.
>=20
> Unless other people start shouting at me, I'm ready to either
> implement, or let Anton implement:
>=20
>=20
> package cirrus.hibernate;
>=20
> interface TransactionFactory {
>   public static TransactionFactory buildTransactionFactory(Properties
> props);
>   public static Transaction beginTransaction(Session session);
>   public Transaction beginTransaction(Session session);
> }
>=20
> interface Transaction {
>   public void commit() throws HibernateException; //flushes session
>   public void rollback() throws HibernateException;
> }
>=20
> package cirrus.hibernate.transaction;
>=20
> public class JTATransaction implements Transaction
> public class JDBCTransaction implements Transaction
> public class CMTTransaction implements Transaction
>=20
> Then our idiom becomes:
>=20
> Session s =3D sf.openSession();
> Transaction t =3D tf.beginTransaction(s);
> try {
>   Foo foo =3D s.load(fooid);
>   foo.setName("FOO");
>   t.commit();
> }
> catch (Exception e) {
>   t.rollback();
> }
> finally {
>   s.close();
> }
>=20
> Thats pretty nice, surely?
>=20
>=20
> _______________________________________________________________
>=20
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>=20
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>=20