> session.sessionWithOptions().connection().openSession() > > says *exactly* what you just said: "open a session using the same connection > as an existing session".
Yes - sorry I didn't get the full thread when writing my initial question ;) > Like I said, I do not think that is enough as I think that if you get the > connection, you also need the "transaction context" holding that connection. > "transacvtion context" here is the TransactionCoordinator. > > session.sessionWithOptions().transactionContext().openSession() Okey and the transactionContext actually continues to lives on even though the source session is closed, correct ? Trying to get my head around some of the old special case assumptions ;) /max > > > On Monday, April 04, 2011, at 04:40 am, Max Rydahl Andersen wrote: >>> RE: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2860 >>> >>> This dealt with cleaning up all the overloaded openSession methods from >>> SessionFactory and SessionFactoryImplementor. >>> >>> The new main method for obtaining a Session is >>> SessionFactory.withOptions() which returns a >>> org.hibernate.SessionBuilder instance which can be used to specify the >>> options with which you want the Session built by eventually calling >>> openSession() on it. For example: >>> >>> Session session = sessionFactory >>> >>> .withOptions() >>> .connection( someConnection ) >>> .openSession(); >>> >>> The only prior form I left is openSession() >>> >>> There is also a means to create a Session using certain information from >>> an existing session using Session.sessionWithOptions() which returns a >>> org.hibernate.SharedSessionBuilder (extending from SessionBuilder). >>> >>> As part of this I was also finally able to remove the long deprecated >>> Session.connection() method since we now have doWork, doReturningWork and >>> now session opening. >>> >>> Any questions or concerns? >> >> Which of these best fits AuditLogInterceptor pattern ? i.e. where you want >> the same connection as a session but do not wish to "pollute" the session >> with entities/state concerning the auditlog entries ? >> >> None of them seem to allow for that as far as I can see ? >> >> They either use different session or have a limited lifecycle not >> permitting keeping a second session around for lookup/state ? >> >> Am I missing something ? >> >> /max >> http://about.me/maxandersen > > --- > Steve Ebersole <st...@hibernate.org> > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev /max http://about.me/maxandersen _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
