I currently do not specify the hibernate.dialect in my configuration (which means Hibernate must be determining the dialect based upon my url, right?) but even if I did, I don't know how to get the property value at runtime. Whatever the case, what's the best way to determine the underlying database at runtime? Thanks in advance, Tom _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Steve, Saw this yesterday. Looks like I'll be able to remove my patch that is currently allowing me to inject my session factory into session obtained from a getCurrentSession() call which makes me very happy. I'll dig up the JIRA so you guys can kill it. One question though, with the session.sessionWithOptions() will that steal the connection from the underlying session? Background: We've got some places where we want to execute a query with an alternate set of filters and rather than muck with the ones on the existing session we'll use session.connection() and spin a new one and set the particular filters we want, do the query and then close the session(). That just leaves the original session isolated from having a bunch of additional data loaded into and also prevents data from being locked into it with the temporary filter view of the data. I just wanted to ensure that this will still be possible. Shawn Clowater -----Original Message----- From: hibernate-dev-bounces(a)lists.jboss.org [mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Steve Ebersole Sent: Friday, April 01, 2011 7:25 AM To: hibernate-dev(a)lists.jboss.org Subject: [hibernate-dev] Session opening 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? --- Steve Ebersole <steve(a)hibernate.org&gt; http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

2011/4/1 Steve Ebersole <steve(a)hibernate.org&gt;: > Shawn, you would use: > session.sessionWithOptions().connection().openSession() > > That connection() call says "use the connection from the underlying > session in the new session". Although I think you are really more > looking for: > session.sessionWithOptions().transactionContext().openSession() > > saying to share transaction context between the 2 sessions that's looking very good! Will it also be possible to use the new session in a different thread, sharing the same transaction? Sanne > On Friday, April 01, 2011, at 11:05 am, Shawn Clowater wrote: >> Steve, >> >> Saw this yesterday. Looks like I'll be able to remove my patch that is >> currently allowing me to inject my session factory into session obtained >> from a getCurrentSession() call which makes me very happy. I'll dig up >> the JIRA so you guys can kill it. >> >> One question though, with the session.sessionWithOptions() will that >> steal the connection from the underlying session? >> >> Background: We've got some places where we want to execute a query with >> an alternate set of filters and rather than muck with the ones on the >> existing session we'll use session.connection() and spin a new one and >> set the particular filters we want, do the query and then close the >> session(). That just leaves the original session isolated from having a >> bunch of additional data loaded into and also prevents data from being >> locked into it with the temporary filter view of the data. I just >> wanted to ensure that this will still be possible. >> >> >> Shawn Clowater >> >> -----Original Message----- >> From: hibernate-dev-bounces(a)lists.jboss.org >> [mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Steve >> Ebersole >> Sent: Friday, April 01, 2011 7:25 AM >> To: hibernate-dev(a)lists.jboss.org >> Subject: [hibernate-dev] Session opening >> >> 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? >> >> --- >> Steve Ebersole <steve(a)hibernate.org&gt; >> http://hibernate.org >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > --- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

Shawn, you would use: session.sessionWithOptions().connection().openSession() That connection() call says "use the connection from the underlying

in the new session". Although I think you are really more looking

session.sessionWithOptions().transactionContext().openSession() saying to share transaction context between the 2 sessions On Friday, April 01, 2011, at 11:05 am, Shawn Clowater wrote: > Steve, > > Saw this yesterday. Looks like I'll be able to remove my patch that

> currently allowing me to inject my session factory into session

> from a getCurrentSession() call which makes me very happy. I'll dig

> the JIRA so you guys can kill it. > > One question though, with the session.sessionWithOptions() will that > steal the connection from the underlying session? > > Background: We've got some places where we want to execute a query

> an alternate set of filters and rather than muck with the ones on

> existing session we'll use session.connection() and spin a new one

> set the particular filters we want, do the query and then close the > session(). That just leaves the original session isolated from

> bunch of additional data loaded into and also prevents data from

> locked into it with the temporary filter view of the data. I just > wanted to ensure that this will still be possible. > > > Shawn Clowater > > -----Original Message----- > From: hibernate-dev-bounces(a)lists.jboss.org > [mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Steve > Ebersole > Sent: Friday, April 01, 2011 7:25 AM > To: hibernate-dev(a)lists.jboss.org > Subject: [hibernate-dev] Session opening > > RE:

> > This dealt with cleaning up all the overloaded openSession methods

> SessionFactory and SessionFactoryImplementor. > > The new main method for obtaining a Session is > SessionFactory.withOptions() > which returns a org.hibernate.SessionBuilder instance which can be

> to > specify the options with which you want the Session built by

> 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

> 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

> Session.connection() method since we now have doWork,

> and now > session opening. > > Any questions or concerns? > > --- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev --- Steve Ebersole <steve(a)hibernate.org&gt; http://hibernate.org

> 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

session.sessionWithOptions().connection().openSession() says *exactly* what you just said: "open a session using the same connection as an existing session".

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

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 <steve(a)hibernate.org&gt; http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

>> 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 ? No, that is not correct. And the same is true of the corollary in the "old code" using its Connection as well. In the old code, if you did: factory.openSession( someExistingSession.connection() ) the new session is screwed once 'someExistingSession' is closed.

> Trying to get my head around some of the old special case assumptions ;) Well my argument is always that assumptions are bad :) Make it a contract