>>> 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 04/05/2011 11:23 AM, Max Rydahl Andersen wrote:
>> 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.sessionWithOpti
> 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 t
Sorry - didn't get the mail thread in proper order (damn VPN!)
>From reading the whole thread I guess the answer is:
session.sessionWithOptions().connection().openSession()
or even
session.sessionWithOptions().transactionContext().openSession()
I'm still a bit fuzzy about where the lifecycle bo
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 tha
> 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
ernate-dev-boun...@lists.jboss.org] On Behalf Of Steve
Ebersole
Sent: Friday, April 01, 2011 11:06 AM
To: hibernate-dev@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
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(
I *believe* so
On Friday, April 01, 2011, at 11:18 am, Sanne Grinovero wrote:
> 2011/4/1 Steve Ebersole :
> > Shawn, you would use:
> > session.sessionWithOptions().connection().openSession()
> >
> > That connection() call says "use the connection from the underlying
> > session in the new sessio
2011/4/1 Steve Ebersole :
> 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().transa
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
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.s
12 matches
Mail list logo
