From: Anton v. S. <an...@ap...> - 2002-05-17 05:18:02
|
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 |