11:30 a.m.
Was thinking some more today about the deprecation of Session.connection()
The reason we deprecated it was that we need a way to scope access to
the Connection because Session may have to release it due to "release
mode". The back story here is that we added "connection release mode"
as a way to fix an earlier problem using Hibernate in certain
container-managed-transaction scenarios involving nested bean calls
where they both used the same Session but the nested bean forced the
session to obtain a Connection first. Hibernate tries to delay
obtaining the JDBC Connection until needed. However, in the stated
scenario that leads to a situation where the container managing the
transaction sees a Connection "leaking" from the nested bean call since
it was the one that forced the Connection to be obtained from the
DataSource. The solution to this back then was to have Hibernate
release the Connection whenever it was done using it for the moment in
JTA cases. In retrospect, I think a much cleaner solution to the above
situation is to force the Session to obtain the Connection up front
rather than this obtain/release as-needed cycle.
So as one more attempt to save Session.connection() from going away, I
wanted to propose that we drop the notion of "release mode" in favor of
simply saying whether or not to aggressively acquire the Connection when
the Session starts. Then all of the concerns that made deprecating and
planning on removing Session.connection() are no longer there.
WDYT?
--
steve(a)hibernate.org
http://hibernate.org
12:47 p.m.
If we have a bean (topbean) invoking another bean (childbean) method
that needs a new JTA transaction
(http://docs.oracle.com/javaee/6/api/javax/ejb/TransactionAttributeType.ht...),
we will want to use separate database connections for the two beans.
I think that this would only be a requirement if a (container managed)
extended persistence context is used since two separate Hibernate
sessions would be used if the persistence context is transaction scoped.
If we are in a JTA transaction, I think that associating the connection
with the transaction could be an alternative to associating the
connection with the session.
On 10/15/2012 12:30 PM, Steve Ebersole wrote:
Was thinking some more today about the deprecation of
Session.connection()
The reason we deprecated it was that we need a way to scope access to
the Connection because Session may have to release it due to "release
mode". The back story here is that we added "connection release mode"
as a way to fix an earlier problem using Hibernate in certain
container-managed-transaction scenarios involving nested bean calls
where they both used the same Session but the nested bean forced the
session to obtain a Connection first. Hibernate tries to delay
obtaining the JDBC Connection until needed. However, in the stated
scenario that leads to a situation where the container managing the
transaction sees a Connection "leaking" from the nested bean call since
it was the one that forced the Connection to be obtained from the
DataSource. The solution to this back then was to have Hibernate
release the Connection whenever it was done using it for the moment in
JTA cases. In retrospect, I think a much cleaner solution to the above
situation is to force the Session to obtain the Connection up front
rather than this obtain/release as-needed cycle.
So as one more attempt to save Session.connection() from going away, I
wanted to propose that we drop the notion of "release mode" in favor of
simply saying whether or not to aggressively acquire the Connection when
the Session starts. Then all of the concerns that made deprecating and
planning on removing Session.connection() are no longer there.
WDYT?
1:14 p.m.
If we associate the db connection with the JTA transaction, I assume
that we would release the connection after the transaction completes.
On 10/15/2012 01:47 PM, Scott Marlow wrote:
If we have a bean (topbean) invoking another bean (childbean) method
that needs a new JTA transaction
(http://docs.oracle.com/javaee/6/api/javax/ejb/TransactionAttributeType.ht...),
we will want to use separate database connections for the two beans.
I think that this would only be a requirement if a (container managed)
extended persistence context is used since two separate Hibernate
sessions would be used if the persistence context is transaction scoped.
If we are in a JTA transaction, I think that associating the connection
with the transaction could be an alternative to associating the
connection with the session.
On 10/15/2012 12:30 PM, Steve Ebersole wrote:
> Was thinking some more today about the deprecation of Session.connection()
>
> The reason we deprecated it was that we need a way to scope access to
> the Connection because Session may have to release it due to "release
> mode". The back story here is that we added "connection release
mode"
> as a way to fix an earlier problem using Hibernate in certain
> container-managed-transaction scenarios involving nested bean calls
> where they both used the same Session but the nested bean forced the
> session to obtain a Connection first. Hibernate tries to delay
> obtaining the JDBC Connection until needed. However, in the stated
> scenario that leads to a situation where the container managing the
> transaction sees a Connection "leaking" from the nested bean call since
> it was the one that forced the Connection to be obtained from the
> DataSource. The solution to this back then was to have Hibernate
> release the Connection whenever it was done using it for the moment in
> JTA cases. In retrospect, I think a much cleaner solution to the above
> situation is to force the Session to obtain the Connection up front
> rather than this obtain/release as-needed cycle.
>
> So as one more attempt to save Session.connection() from going away, I
> wanted to propose that we drop the notion of "release mode" in favor of
> simply saying whether or not to aggressively acquire the Connection when
> the Session starts. Then all of the concerns that made deprecating and
> planning on removing Session.connection() are no longer there.
>
> WDYT?
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4455
days inactive
4455
days old
2 comments
2 participants
participants (2)
-
Scott Marlow -
Steve Ebersole