Maybe, in our case we just wanted a session outside of the main one that
could still see the uncommitted (but flushed) data but could apply
alternate filtering and also avoid an infinite flush loop in some cases.
The key is that we might be looking at some newly inserted/updated
records and don't want to get deadlocked within the same unit of work.
I can live with the answer that's we've been overcomplicating this for
years by trying to also obtain the same physical connection.
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 11:06 AM
To: hibernate-dev(a)lists.jboss.org
Subject: Re: [hibernate-dev] Session opening
Actually, i wonder now if allowing just the connection to be shared
makes any
sense. Maybe it needs to always be the transaction context in those
cases?
On Friday, April 01, 2011, at 11:11 am, Steve Ebersole wrote:
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
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>
>
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>
http://hibernate.org
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev