I know that commit() and cancel() were recently deprecated, but I'm thinking
it might be a good idea to add some methods for a slightly more general
transaction handling mechanism to the Session class.
What I have in mind is that Session would support at least three additional
methods, something like beginTransaction, commitTransaction, and
rollbackTransaction. These would delegate to an object which implements a
"SimpleTransactionManager" interface with those methods. Hibernate could
supply a couple of really simple implementations of this interface, e.g. one
which just maps to JDBC calls, and perhaps one which maps to "BEGIN TRAN",
"COMMIT TRAN", "ROLLBACK TRAN" statements as appropriate for the SQL
dialect. The user could tell the SessionFactory what transaction mechanism
is required, with the option of supplying alternative implementations. This
could mean that application code could switch the underlying transaction
handling mechanism without changing the client code, and could fairly easily
support things like nested transactions.
I realize this might be more or less irrelevant in some application server
environments, but I think it could be cleaner for simpler applications, and
would eliminate the dependency on direct Connection calls via
session.connection(). Of course, direct use of the Connection would still
be possible, so this wouldn't impose or enforce anything, or break backward
compatibility.
IMO, the transaction-handling idiom would become a bit neater and better
abstracted:
Session sess = factory.openSession();
try {
sess.beginTransaction();
//do some work
...
sess.commitTransaction();
}
catch (Exception e) {
sess.rollbackTransaction();
throw e;
}
finally {
sess.close();
}
I already do this via a Session wrapper of my own, but I'd be happy to
integrate something like this into Hibernate if it's considered worthwhile.
Any feedback is appreciated.
Anton
|
