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