> 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 _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ _______________________________________________ Hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
