hibernate-devel — development

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

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

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

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

[Hibernate-devel] Transaction changes checked in

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

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.

There are only two small changes to existing code, both in the
cirrus.hibernate package.  Existing client code should be unaffected by
this, so the change is completely optional for users.

The changes are summarized below, for convenience.  I've included the actual
source code (minus comments), except for the two new classes, since it's so
short and summarizes the changes well.  I'll send a separate message with
some design issues that I have questions about.

In Hibernate.java, the following two methods were added:

	public static TransactionFactory buildTransactionFactory() throws
HibernateException {
		return new TransactionFactoryImpl();
	}

	public static TransactionFactory buildTransactionFactory(Properties
transactionProps) throws HibernateException {
		return new TransactionFactoryImpl(transactionProps);
	}

In Environment.java, the following definition was added:

	public static final String TRANSACTION_STRATEGY =
"hibernate.transaction_strategy";

In addition to the above, there are two new public interfaces in
cirrus.hibernate:

	public interface Transaction {
		public void commit() throws HibernateException;
		public void rollback() throws HibernateException;
	}

	public interface TransactionFactory {
		public Transaction beginTransaction(Session session) throws
HibernateException;
	}

Then there's a new package, cirrus.hibernate.transaction.  This contains one
"internal" interface:

	interface TransactionImplementor extends Transaction {
		public void begin(Session session) throws HibernateException;
	}

cirrus.hibernate.transaction also contains two new classes, so far:

	class TransactionFactoryImpl implements TransactionFactory;
	class JDBCTransaction implements TransactionImplementor;

That's it.  I also added a line to the changelog under 0.9.14.

I haven't yet implemented JTATransaction or CMTTransaction, although
obviously they ought to be pretty simple (if not completely empty).  I've
performed only limited tests so far, to make sure my own application could
use the new functionality, and that existing code didn't break.  Of course,
the changes are such that existing code is unlikely to be affected.

Let me know if I've forgotten anything.  Feel free to change anything at
all, or if you'd like me to make particular changes.  I'm going to be doing
some work integrating into my own application, and will enhance the
transaction code as necessary, as I go along.

Anton

Re: [Hibernate-devel] Additional exception case in ClassPersister.setPropertyValues

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

Cool. Thanks for that. I realised another cases would also benefit from
that fix so I refactored the exception handling out onto ReflectHelper.

Made a few other changes this weekend:

1. Got it re - working and compiling in JDK 1.2 (proxies transparently
disabled)
2. session is now much cleverer about how often it needs to flush itself.
It only flushes before a query execution if it could contain changes to any
of the queried tables. (rather than before _every_ query)
3. fixed a problem with native key generation + not-null constaints on
foreign keys.
4. added a column type override (attribute sql-type of <column> tag)

and a couple of other little changes.

I want Anton's Transaction API + Jon's composite id query patch and then
I'm prepared to declare a functionally complete 1.0rc. At that point I've
promised myself not to write anymore code until the documentation is
improved.

For those who havn't checked out 0.9.13 yet, go have a look......

[Hibernate-devel] Additional exception case in ClassPersister.setPropertyValues

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

I ran into a problem where a NullPointerException was being thrown from deep
inside Hibernate (latest version), with no real clue as to what the problem
was:

java.lang.NullPointerException
	at java.lang.reflect.Method.invoke(Native Method)
	at
cirrus.hibernate.impl.ClassPersister.setPropertyValues(ClassPersister.java:4
49)
	at cirrus.hibernate.impl.ClassPersister.hydrate(ClassPersister.java:680)
	at
cirrus.hibernate.impl.RelationalDatabaseSession.loadFromResultSet(Relational
DatabaseSession.java:1133)
	...

It took me a while to figure out where to look.  It turned out that there
was a null value in my database, in a column with a setter method that
expects a Java double - so really, the problem was either with my data or
with the setter method, depending on how you look at it.  To make the error
message more helpful in future, I've added an exception case to
ClassPersister.setPropertyValues:

	catch (NullPointerException npe) {
		throw new HibernateException(
			"NullPointerException occurred inside setter for class "
			+ className
			+ ", property "
			+ propertyNames[j]
		);
	}

I've checked the change into CVS - if there's a better way to handle this,
please let me know.

Anton

RE: [Hibernate-devel] Simple transaction management

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

Gavin,

You suggested:

> interface TransactionFactory {
>   public static TransactionFactory buildTransactionFactory(Properties
props);
>   public static Transaction beginTransaction(Session session);
>   public Transaction beginTransaction(Session session);
> }

I assume buildTransactionFactory() needs to be defined somewhere other than
on the interface it's a factory method for.  Did you have somewhere in mind?
It could be added to Datastore, but I don't know if that's an acceptable
change to an existing interface.  Or, TransactionFactory could be made into
an publicly exposed class, but that seems a little messy to me.

Anton

[Hibernate-devel] 0.9.12 (was: Simple transaction management)

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

>> Unless other people start shouting at me, I'm ready to either
>> implement, or let Anton implement

> I'd be happy to work on this, to make up for having introduced
> this last-minute reshuffle.  Let me take a look at it on Wednesday
> and/or Thursday, and I'll report back once I've done that.

Cool. Lets pencil that stuff in for 0.9.13. My task-list looks like:

1. documentation updates, esp. for the new-style subclass discriminators
2. some extra testing
3. package + release 0.9.12.

The <class discriminator="...."> style of mapping is now deprecated and
replaced with:

<class name="Foo" discriminator-value="0">
  <id ..... />
  <discriminator type="int" column="subclass_code"/>
  ...
  <subclass name="Bar" discriminator-value="1">
    ...
    ...
  </sublcass>
</class>

if discriminator-values are not specified, we default to the fully
qualified classname, as at present.

Together with the new Session.update() methods, working proxies (lazy
object initialization) and all the new bugfixes + optimizations, this is an
important release that considerably enhances functionality and performance!

P.S. I have one more code change to do when I get back tonight. Previously
collections of entities were loaded using n+1 selects. (ie. one select to
grab indexes and ids, then one for each id.) This was a Bad Thing, clearly.
I will add a cute little 1-line hack to reduce this to exactly 2 selects.
(I know its possible with just 1 select but that would require _very_
significant code changes and would depend upon use of an outer join to
precisely maintain the current semantics.)

Just in case you were wondering, Session.find() retrieves objects with 1
select, while Session.iterate() uses n+1, (with the n performed lazily).

RE: [Hibernate-devel] Simple transaction management

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

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

Makes sense.

>...
>
> Session s = sf.openSession();
> Transaction t = tf.beginTransaction(s);
> try {
>   Foo foo = s.load(fooid);
>   foo.setName("FOO");
>   t.commit();
> }
> catch (Exception e) {
>   t.rollback();
> }
> finally {
>   s.close();
> }
>
> Thats pretty nice, surely?

Yes, it's excellent, thank you.  (Don't think I didn't notice that
beginTransaction() wasn't added to Session, though!  Sneaky but smart... :)

> Unless other people start shouting at me, I'm ready to either
> implement, or let Anton implement

I'd be happy to work on this, to make up for having introduced this
last-minute reshuffle.  Let me take a look at it on Wednesday and/or
Thursday, and I'll report back once I've done that.

I may respond to other parts of your message tomorrow - I was out all day
today.

Anton

RE: [Hibernate-devel] Simple transaction management

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

don't get me wrong, i don't despise this change at all. :-)  i just
remember when i was first using hibernate, i got it going in a stanalone
application.  i then tried using it in a CMT environment, which was a
little frustrating because back then u still had to call commit, which
certainly isn't intuitive.

however, all is ok, as the flush method is staying on session.  we
simply need a code example in the docs showing the general code
structure in different environments (which i don't mind helping out on).

brad



> -----Original Message-----
> From: Gavin_King/Cirrus%CI...@ci...
> [mailto:Gavin_King/Cirrus%CI...@ci...]
> Sent: Tuesday, 21 May 2002 5:17 PM
> To: hib...@li...
> Subject: RE: [Hibernate-devel] Simple transaction management
>=20
>=20
>=20
> > forgive me if this a brain dead question - i am just=20
> 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=20
> used in a CMT
> > environment?  i was just concerned that a commit is going=20
> to replace the
> > flush, which doesn't make sense (in this environment).
>=20
>=20
> For a CMTTransaction or JTATransaction Transaction.commit() would call
> Session.flush().
> For a JDBCTransaction Transaction.commit() would call=20
> Session.flush() then
> Session.connection().commit().
>=20
> The call to flush() is just an extra convenience. Essentially
> Transaction.commit() has empty implementations for container managed
> transactions and a non-empty implementation for JDBC transactions....
>=20
> Brad, I don't see any other sensible approach to this. If we want to
> abstract the underlying transaction mechanism, as agrued by=20
> Anton, there
> has to be a method which indicates conclusion of the unit of=20
> work (because
> JDBCTransaction needs to call commit() from there). There=20
> also needs to be
> a method which forces rollback ( whether it calls rollback() or
> setRollbackOnly() ). If you really object to the first method=20
> being called
> commit(), what else should we call it?
>=20
> I guess if you really despise this, you can continue using the current
> approach. I am not proposing ANY change at all to existing code.
>=20
> Otherwise suggest a better alternative....
>=20
> Gavin
>=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

RE: [Hibernate-devel] Simple transaction management

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

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


For a CMTTransaction or JTATransaction Transaction.commit() would call
Session.flush().
For a JDBCTransaction Transaction.commit() would call Session.flush() then
Session.connection().commit().

The call to flush() is just an extra convenience. Essentially
Transaction.commit() has empty implementations for container managed
transactions and a non-empty implementation for JDBC transactions....

Brad, I don't see any other sensible approach to this. If we want to
abstract the underlying transaction mechanism, as agrued by Anton, there
has to be a method which indicates conclusion of the unit of work (because
JDBCTransaction needs to call commit() from there). There also needs to be
a method which forces rollback ( whether it calls rollback() or
setRollbackOnly() ). If you really object to the first method being called
commit(), what else should we call it?

I guess if you really despise this, you can continue using the current
approach. I am not proposing ANY change at all to existing code.

Otherwise suggest a better alternative....

Gavin

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

RE: [Hibernate-devel] Simple transaction management

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

> I think that separating the Transaction and the Session 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();

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 )

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

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

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

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.

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

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.

> 2. Since it incorporates Session functionality, there's no need for
> the developer to manage two objects, a session and a transaction.

As I see it, this is the main advantage to your model. maintaining
pointers to both objects _does_ make application code messier.

> 3. It's not necessary to call both flush() and commit() on a
> TransactionalSession.

As above, I'm happy if Transactions flush the Session.


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

I am soooo not keen on this. The main reasons we wanted to do all
this in the first place were:

1. Abstract application code from the actual transaction mechanism
( and away from JDBC.setAutocommit() ).
2. Be easier to learn.

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.

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

:)

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

Heh, in my comment about dummies I certainly meant no disrespect
to sensible people who prefer simpler APIs over complicated ones
:-)

> In a sense, TransactionalSession isn't that different from the
> deprecated Session API, with its commit and cancel methods.

Exactly. And people found the old API confusing.

> > Properties props = new Properties();
> > props.setProperty("hibernate.transaction_strategy", "JTA");
> > TransactionFactory txFactory =
Hibernate.createTransactionFactory(props);

> The question would arise of whether a beginTransaction() method (or
> createTransaction() or whatever)

I get the impression we will all agree on beginTransaction() :)


> > (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?

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

quite.

> > (2a) For swappable Transaction strategies to work, JTATransaction would
> > need to look up the surrent transaction in JNDI. Is this 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 need to revert to
> >
> > Transaction tx = new ContainerTransaction(session, ejbContext);

> 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.  Users with
> different requirements can tweak them, improve them, write their own,
> or just complain.  The docs could ask for feedback about this.

quite.

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

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.

Unless other people start shouting at me, I'm ready to either
implement, or let Anton implement:


package cirrus.hibernate;

interface TransactionFactory {
  public static TransactionFactory buildTransactionFactory(Properties
props);
  public static Transaction beginTransaction(Session session);
  public Transaction beginTransaction(Session session);
}

interface Transaction {
  public void commit() throws HibernateException; //flushes session
  public void rollback() throws HibernateException;
}

package cirrus.hibernate.transaction;

public class JTATransaction implements Transaction
public class JDBCTransaction implements Transaction
public class CMTTransaction implements Transaction

Then our idiom becomes:

Session s = sf.openSession();
Transaction t = tf.beginTransaction(s);
try {
  Foo foo = s.load(fooid);
  foo.setName("FOO");
  t.commit();
}
catch (Exception e) {
  t.rollback();
}
finally {
  s.close();
}

Thats pretty nice, surely?

RE: [Hibernate-devel] Simple transaction management

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

Gavin,

Your latest proposals, with the factory correction, make for a very clean
design.  I'd be happy enough with a mechanism like this, and I'm willing to
work on developing it.

I have a "but", though, as you might have guessed.  The good news is that I
think that what I'd like to see can be implemented as a trivial wrapper on
top of your latest design, so the question just becomes whether or not this
sort of wrapper ought to become an official part of Hibernate.

I think that separating the Transaction and the Session 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();

I know this must seem very picky, but it seems to me that this is another
case where if the idiom is always the same, a single method ought to be able
to handle it, also preventing potential mistakes (like forgetting to flush -
I'll avoid the metaphors that come to mind :)  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.

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.

The wrapper I'd like to propose involves a slight change in direction,
driven by the desire to keep the Session interface as unchanged as possible.
To achieve this, a TransactionalSession interface would extend the Session
interface, or possibly inherit from a common parent.  [The name
TransactionalSession is provisional, for clarity in the discussion.]

The TransactionalSession interface would have a recommended usage slightly
different from that of the Session interface.  The Session interface would
be retained as is, and would still support developers who want to manipulate
their connections directly, or use transaction objects directly.  The
Session interface would also continue to support sessions without an overall
transaction.

The TransactionalSession interface would be used something like this:

  TransactionalSession tx = factory.beginTransaction(session);
  try {
    myObj = tx.load(MyClass.class, key);
    //...
    tx.commit();
  }
  catch (Exception e) {
    tx.rollback();
    throw e;
  }
  finally {
    tx.close();
  }

The biggest differences here are:

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.

2. Since it incorporates Session functionality, there's no need for the
developer to manage two objects, a session and a transaction.

3. It's not necessary to call both flush() and commit() on a
TransactionalSession.  A class like "RelationalDatabaseTransactionalSession"
would have a commit() method implemented like this:

	this.flush();	// inherited from RelationalDatabaseSession
	this.transaction.commit();	// delegate commit to underlying
strategy-specific transaction object

Although this means that flush() would be deprecated in the
TransactionalSession interface, it would remain a valid method in the
Session interface.

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.  It's
quite conceivable you'd want to use both Sessions and TransactionalSessions
in the same program, although probably not at the same time.  I think there
are various ways to address this, but I'll leave that until we're more in
sync on the basics.  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 :)

In a sense, TransactionalSession isn't that different from the deprecated
Session API, with its commit and cancel methods.  However, I suspect that
one of the objections to integrating a more generalized transaction handling
mechanism into the Session interface, has been the complexity it would add
to the implementation(s) of Session.  TransactionalSession ought to be a
fairly simple combination of the session and transaction objects, which
would be able to make more specific assumptions about some things, and avoid
complicating the Session implementation with extra conditional logic.

I haven't addressed the question of how the factory for
TransactionalSessions would work, but that's pretty much orthogonal to the
API used for actual transactions.  Your suggestion sounds fine to me:

> Properties props = new Properties();
> props.setProperty("hibernate.transaction_strategy", "JTA");
> TransactionFactory txFactory = Hibernate.createTransactionFactory(props);

The question would arise of whether a beginTransaction() method (or
createTransaction() or whatever) should be implemented on the SessionFactory
interface,  for maximum integration of TransactionalSessions; or whether a
TransactionalSessionFactory is needed.  I think this is a separate issue
from the TransactionFactory involved with the choice of transaction
strategy.

Here are my answers to the questions you raised:

> (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?

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.

> (2a) For swappable Transaction strategies to work, JTATransaction would
> need to look up the surrent transaction in JNDI. Is this 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 need to revert to
>
> Transaction tx = new ContainerTransaction(session, ejbContext);

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.  Users with different requirements
can tweak them, improve them, write their own, or just complain.  The docs
could ask for feedback about this.

> (3) Is the call to tx.begin() really necessary in approach (1)??
> Surely the work could be done in the constructor....

As you can tell from my TransactionalSession wrapper, I agree with this.

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

Anton

RE: [Hibernate-devel] Simple transaction management

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

Woops. I really meant to write this in the last mail on this topic:

Properties props = new Properties();
props.setProperty("hibernate.transaction_strategy", "JTA");
TransactionFactory txFactory = Hibernate.createTransactionFactory(props);

Then, for (1):

Transaction tx = txFactory.createTransaction(session);

Or, for (2):

Transaction tx = txFactory.createTransaction();

[Hibernate-devel] Session.update()

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

We had some discussions a while ago about the problem of saving changes to
the state of an object loaded by session A in a new session B. I ended up
not implementing the functionality at that time because the approach I was
thinking of just didn't feel right. I have now implemented this operation
with what I hope is much more natural semantics (and MUCH higher
performance). However, the cost is that there are certain limitations upon
when you can use this operation.

I've implemented

session.update(id, obj);
session.update(obj);

to associate the transient object obj with the session, only if the
persistent object with the given id is _not_ already loaded by the session.
(If the persistent object _is_ already loaded, an exception is thrown.)
Then, when the session is flushed, the current persistent state will be
overwritten by the state of obj. This avoids the following problem with the
semantics considered previously: if the persistent object was already
loaded, we would have had to _copy_ the state of obj into the already
loaded object (which might have been referenced by other persistent
objects), which is a bit non-intuitive to the user.

Secondly, obj may NOT belong to a class that owns top-level collections or
subcollections. This restriction saves us from having to load up the
existing object to delete its existing collection elements. (We can update
nested collections without needing to load them first, because they have
the same id as obj.) This is a reasonable restriction, users don't really
want the SQL UPDATE to be preceded by a SELECT. (Can always implement some
more advanced algorithm here in the future if this restriction is odious.)

The remaining problem (so i thought) is that obj might hold references to
other transient objects. But this is analogous to the state after:

Foo foo = new Foo();
Foo bar = new Bar();
foo.setFoo(bar);
session.save(foo);

I have redefined what happens when a persistent object holds a reference to
a transient object at flush() time. Now the persistent object may be
updated, using the id held by the transient object. (Previously an
exception was thrown by hibernate.) If theres no persistent object with
that ID, an exception will still be thrown by the foreign key constraint
violation.

This decision allows us to selectively update() individual objects in a
graph of transient objects, without losing the relationships between them.

It all feels really nice to me + was easy to implement. A LOT of users
(including me) wanted this functionality.

Gavin

RE: [Hibernate-devel] Simple transaction management

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

Thanks everyone for the input. Havn't been responding in detail because I
wanted to get other views and because I dont have a very strong view and
also cos I've been busy coding some new functionality and reworking some
older code to perform better. The next release will be a pretty major
update :) It would be nice if some of you guys would try out the CVS
version at this stage.

Okay, Anton has convinced me of the need for _something_. I notice that
some other OO persistence frameworks use a Manager interface and a
Transaction interface, where the Transaction object is short-lived and
implements only begin/commit/rollback and the Manager is a long-lived
object. For Hibernate, I hadn't seen the need for a seperate Transaction
object since the Session object is short-lived. I'm now happy to reverse
this decision. Rather than mix begin/commit/rollback methods onto the
Session, where they dont really fit very comfortably, lets have a seperate
object that controls transaction boundaries for a Session (and abstracts
the underlying JTA or JDBC transactions). A Session can span multiple
Transactions, to support the "long transactions with versioning" approach.

ie. What I'm suggesting is, rather than having the user create the Session
by passing a TransactionStrategy object and then having the Session
delegate begin/commit/rollback, just let the user manipulate the
transaction strategy object directly.

This leaves us the freedom to change all this at a later date, without
leaving a million deprecated methods lying around on Session.

The remaining question (if other people agree to this approach) is how the
user obtains Transactions and how they associate the Session with the
Transaction. I can think of some alternatives:

EITHER (1):

Session s = factory.openSession();
Transaction tx = new JDBCTransaction(s);
tx.begin();
try {
  s.update(object); //new method I just wrote ;)
  s.flush();
  tx.commit();
}
catch (Exception e) {
  tx.rollback();
  throw e;
}
finally {
  s.close();

}

OR (2):

Transaction tx = new JTATransaction();

Session s = factory.openSession();
tx.begin(s);
try {
  s.update(object);
  s.flush();
  tx.commit(s);
}
catch (Exception e) {
  tx.rollback(s);
  throw e;
}
finally {
  s.close();
}


OR (3):

Properties props = new Properties();
props.setProperty("hibernate.transaction_strategy", "JDBC");
Session s = factory.openSession(props);
Transaction tx = s.beginTransaction();
try {
  s.update(object);
  s.flush();
  tx.commit();
}
catch (Exception e) {
  tx.rollback();
  throw e;
}
finally {
  s.close();
}

I like both (1) and (2) for not requiring modifications to the current API
(which is an enormous plus to me). All three leave the existing API
meaningful ( flush() + close() + connection() are all still useful ) so no
more deprecations (this makes me very comfortable).

(2) has the advantage that a single Transaction object could be used for
multiple Sessions (if, for example, there were multiple databases). I'm not
sure if thats particularly useful ... the other approaches still allow
multiple Sessions per transaction, but with multiple Transaction objects...

To fully benefit from the abstraction that Anton is after, (1) and (2)
would probably require a TransactionFactory interface (to let us swap
JDBCTransaction for JTATransaction somewhat transparently).

Properties props = new Properties();
props.setProperty("hibernate.transaction_strategy", "JTA");
TransactionFactory factory = Hibernate.createTransactionFactory(props);

Then, for (1):

Transaction tx = TransactionFactory.createTransaction(session);

Or, for (2):

Transaction tx = TransactionFactory.createTransaction();

So, in defence of approach (3) above, you end up with a simpler API.

Other questions in my mind:

(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?

(2a) For swappable Transaction strategies to work, JTATransaction would
need to look up the surrent transaction in JNDI. Is this 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 need to revert to

Transaction tx = new ContainerTransaction(session, ejbContext);

(3) Is the call to tx.begin() really necessary in approach (1)?? Surely the
work could be done in the constructor....

Okay, cut me down if all this still aint enough.

thanks

Gavin

[Hibernate-devel] JDBC transaction management considered harmful

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

I mentioned this in passing in another message, but wanted to lay out
explicitly why I don't like direct use of a JDBC connection for transaction
handling.  It's very simple:

To begin and end transactions reliably with a JDBC connection, you need to
use setAutoCommit().  However, this method doesn't just begin or end a
transaction: it changes the state of the connection for all subsequent use.
There isn't a method which says "end the current transaction and do not
begin another one".  This, coupled with the fact that connections are
typically used for multiple successive transactions, is bad design, because
it means that a mistake in one transaction can affect subsequent
transactions.

So one of the factors behind my suggesting that Hibernate should wrap
connections and support management of transactions, is simply that I
consider code such as:

	conn.commit();
	conn.setAutoCommit(true);

to be unacceptable, if it needs to be inserted at the end of every
transaction throughout a system.

Sure, one can argue that this isn't such a big deal, it's just an idiom that
you have to follow consistently to avoid getting in trouble.  That can work
if you're a good individual developer and aren't worrying about the
productivity of teams.  But still, every tenet of abstraction and good
design says that when you have code that is repeated the same way all over
the place, which can have negative consequences if not repeated exactly,
then you should abstract that code into a method.

Sorry if I'm (re)stating the obvious, but this is an important design point
which may not be obvious from faithfully following Sun's documentation.

Anton
P.S. horse=null;)

RE: [Hibernate-devel] Simple transaction management

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

> The new API is a much better solution in terms of (2), (3) and (4) -
> particularly (2) - but still requires a fairly lengthy explanation
about
> how to actually end a Session - something that should, on the face of
it,
> be so damn simple!!

i think this could be dealt with by changing/re-organising the docs a
little (no matter what is decided out of this discussion) so that there
is a section on usage scenarios with an example for say: ejb container,
standalone app where hibernate gets the connection for u, standalone app
where u supply a connection.  each example should include the session
factory properties and the try/catch/finally block for manipulating
persistent objects.

> I think part of the problem is that the relationship between a Session
and a
> transaction isn't as clear as it might be, and this is at least partly
> because the separation between the two is currently implemented by
saying
> "here's the connection, you're on your own with transactions".  I
imagine
> this is likely to encourage the tendency of users to think of a
session as
> being like a connection, which you can use repeatedly for multiple
> transactions.

i think this point is somewhat valid, even though the section titled
"Sessions, Transactions and Threads" in the docs is pretty specific on
the fact that transactions are delegated to the jdbc connection.

unless the session behaviour is changed to support re-use for multiple
transactions, adding a begin transaction type method in the api anywhere
might increase the tendancy of user's to think of a session as being
like a connection.

if it wasn't for the ability to open a session by passing in a
connection, i think commit & rollback methods on the session would be ok
- as long as they don't close the session, as that should go in a
finally block.  commit could flush and call commit on the connection -
as long as the docs made it clear that commit did this.  perhaps having
a separate transaction management class that threw an exception if it
were used inappropriately for the environment it is in would get around
my concern when using an external connection.

if there r going to be commit & rollback type methods i think they
should be called commit & rollback, or have those words in them as these
are generally accepted and known terms.

having said all that, i don't have a problem with the current api - i
haven't written a transaction management wrapper (maybe i am missing
something :-)) - however, most of our non-read type operations are
currently done in ejbs using container managed transactions.  i
initially thought that calling commit/rollback directly on the
connection wasn't very elegant, but it does help to re-inforce that
transactions are delegated to the jdbc connection.  i found this also
helped when understanding integrating hibernate in an application
server.

brad

Re: [Hibernate-devel] Simple transaction management

[Phillip B. <phi...@cl...>]

I'd just like to say I agree with what Anton has been saying about 
simplifying transaction management.  The relationship between Sessions 
and transactions isn't as clear as it could be.

Although I haven't done much with Hibernate the first thing I did do was 
put a transaction wrapper around Session so I could get back to thinking 
about transactions rather than sessions.  This sounds a lot like what 
Anton did.  If more than one of us is inventing this wheel, then either 
we're both doing things wrong or maybe a wheel needs to be built.

My NZD$0.02.

/PhillipB

Re: [Hibernate-devel] release plans (was: Queries on objects with composite keys...)

[Jon L. <jon...@xe...>]

I found the test class and I was able to run them with no problem.  I'll 
probably have time to add the tests for the composite-key queries on 
Monday or Tuesday...  If you are going to release a new version next 
week, I will probably hold off submitting my patches until I can apply 
them to the new version just to be safe.

On Saturday, May 18, 2002, at 05:53  AM, 
Gavin_King/Cirrus%CI...@ci... wrote:

>> I just wanted to give you a quick update... I have the query by
>> composite keys working now. I will do some more testing throughout
>> the weekend and early next week to make sure that everything else still
>> works. If it everything checks out with no problems, I'll post the
>> patches the middle of next week.
>
> Great! Have you figured out how to run FooBarTest yet? If so, could you 
> add
> tests of the composite key query funtion in there. The class Fum is the
> existing composite-key test class (but feel free to add your own).
>
> I will probably release 0.9.12 before middle-of-next week, so this might
> miss out on the next release. So my plans are looking like:
>
> 0.9.12 - as soon as I finish the configurable discriminator column code
> 0.9.13 - integrate other people's patches (by Christoph Beck + Jon 
> Lipsky)
> - documentation
> 1.0rc1 - [Feature Freeze]
> - more TestCases (probably port existing tests to JUnit)
> - documentation!
> 1.0.0 - (I hope)
>
> The only thing that could throw this off is if a rework of the Session 
> API
> (as suggested by Anton) is really necessary. Even then, I'm tempted to
> delay it to version 1.1 to let the dust settle....
>
>
> _______________________________________________________________
> Hundreds of nodes, one monster rendering program.
> Now that's a super model! Visit http://clustering.foundries.sf.net/
>
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel

RE: [Hibernate-devel] release plans (was: Queries on objects with composite keys...)

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

> The only thing that could throw this off is if a rework of the Session API
> (as suggested by Anton) is really necessary.

It's tempting to say I'd like to see something along these lines in v1.0,
just from the point of view of starting out with the API being as stable as
possible.  But if everything else is ready, I don't know that it's important
enough to delay for.

> Even then, I'm tempted to
> delay it to version 1.1 to let the dust settle....

Won't some of the features in 1.0 still be "experimental"?  Perhaps an
"experimental connection wrapper" could be included in 1.0, with no promises
that (that part of) the API won't change in future.  What I have in mind
ought to be simple enough not to require a great deal of development or
testing - it'll probably take longer to agree on what it should look like,
than to implement.

Anton

[Hibernate-devel] release plans (was: Queries on objects with composite keys...)

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

> I just wanted to give you a quick update... I have the query by
> composite keys working now. I will do some more testing throughout
> the weekend and early next week to make sure that everything else still
> works. If it everything checks out with no problems, I'll post the
> patches the middle of next week.

Great! Have you figured out how to run FooBarTest yet? If so, could you add
tests of the composite key query funtion in there. The class Fum is the
existing composite-key test class (but feel free to add your own).

I will probably release 0.9.12 before middle-of-next week, so this might
miss out on the next release. So my plans are looking like:

0.9.12 - as soon as I finish the configurable discriminator column code
0.9.13 - integrate other people's patches (by Christoph Beck + Jon Lipsky)
- documentation
1.0rc1 - [Feature Freeze]
- more TestCases (probably port existing tests to JUnit)
- documentation!
1.0.0 - (I hope)

The only thing that could throw this off is if a rework of the Session API
(as suggested by Anton) is really necessary. Even then, I'm tempted to
delay it to version 1.1 to let the dust settle....

[Hibernate-devel] PoolMan

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

Ages ago, Brad Clow wrote:

> PoolMan (http://www.codestudio.com) is no longer supported by its
> developer and we found that the last release had some issues.  it may
> yet end up with the jakarta project
> (http://jakarta.apache.org/site/elsewhere.html#0305).

I tried out various versions of PoolMan with hibernate and
concluded that Brad is correct. It has issues and since no
longer supported, I imagine they won't be going away! (The
issues were bad enough that I couldn't run test suite.)

On the other hand, c3p0 bugs get fixed immediately I find
them. I would _love_ to get some feedback about how
peoples applications perform with c3p0 pooling enabled,
compared to hibernate's own (crap) connection pool.

You need to set the following properties

hibernate.c3p0.max_size {max size of connection cache}
hibernate.c3p0.min_size {min size of connection cache}
hibernate.c3p0.timeout  {max time a connection can remain idle}
hibernate.c3p0.max_statements {size of statement cache}

hibernate.pool_size 0

You may want to grab the latest jar from

http://sourceforge.net/projects/c3p0

Or from lib directory in our CVS.