4:06 a.m.
I created a new pull request for master.
https://github.com/hibernate/hibernate-orm/pull/322
I have not created a pull request for metamodel yet, but I believe the only difference
from the master pull request would be:
- SessionBuilderImplementor.owner(SessionOwner) would be moved into SessionBuilder
- references to SessionBuilderImplementor would be changed back to SessionBuilder.
Please take a look.
Thanks,
Gail
4:08 a.m.
----- Original Message -----
From: "Gail Badner" <gbadner(a)redhat.com>
To: "Hibernate hibernate-dev" <hibernate-dev(a)lists.jboss.org>
Cc: "Steve Ebersole" <steve(a)hibernate.org>, "Scott Marlow"
<smarlow(a)redhat.com>
Sent: Tuesday, May 1, 2012 1:06:55 AM
Subject: New pull request for HHH-7265 (ConcurrentModificationException)
I created a new pull request for master.
https://github.com/hibernate/hibernate-orm/pull/322
I have not created a pull request for metamodel yet, but I believe
the only difference from the master pull request would be:
- SessionBuilderImplementor.owner(SessionOwner) would be moved into
SessionBuilder
- references to SessionBuilderImplementor would be changed back to
SessionBuilder.
- SessionBuilderImplementor could be removed.
Please take a look.
Thanks,
Gail
10:15 a.m.
Is this the safest way to fix?
What are the different use cases that SessionImpl.shouldAutoClose()
needs to handle? Identifying each one, will help me to review the code
change.
Concerns:
1. The patch is changing the serialization of Hibernate Sessions to
include the session owner. Where is org.hibernate.SessionOwner? Is
org.hibernate.SessionOwner always serializable? Could
org.hibernate.SessionOwner reference anything that could be problematic
for serialization?
2. AbstractSessionImpl doesn't have a serialVersionUID but with this
change to the Session serialization, I'm wondering if it should.
3. Could this change introduce session leaks where the session owner
doesn't close the session?
4. Where is SessionBuilderImplementor?
5. I see that the EntityManager will no longer register a
synchronization with the transaction synchronization registry. Are we
introducing any problems by marking the EntityManager as closed, even
though we are deferring the close? How exactly will the session be
closed after this EntityManager.close() code is reached (where is the
call to EntityManager.shouldAutoCloseSession() coming from)?
Scott
On 05/01/2012 04:08 AM, Gail Badner wrote:
----- Original Message -----
> From: "Gail Badner"<gbadner(a)redhat.com>
> To: "Hibernate hibernate-dev"<hibernate-dev(a)lists.jboss.org>
> Cc: "Steve Ebersole"<steve(a)hibernate.org>, "Scott
Marlow"<smarlow(a)redhat.com>
> Sent: Tuesday, May 1, 2012 1:06:55 AM
> Subject: New pull request for HHH-7265 (ConcurrentModificationException)
>
> I created a new pull request for master.
>
> https://github.com/hibernate/hibernate-orm/pull/322
>
> I have not created a pull request for metamodel yet, but I believe
> the only difference from the master pull request would be:
> - SessionBuilderImplementor.owner(SessionOwner) would be moved into
> SessionBuilder
> - references to SessionBuilderImplementor would be changed back to
> SessionBuilder.
- SessionBuilderImplementor could be removed.
>
> Please take a look.
>
> Thanks,
> Gail
11:58 a.m.
Currently session auto-closing is driven solely by
Settings.isAutoCloseSessionEnabled(), which in turn comes from
'hibernate.transaction.auto_close_session' setting. The problem is
that in cases where the session is "owned" (HEM and Envers are 2 such
cases) the answer is not always as simple as an a priori boolean flag.
That is the case Gail is trying to solve. To be honest I have not yet
looked at the pull request to answer your specifics. But I will look
at it and apply it prior to 4.1.3 tomorrow.
On Tue 01 May 2012 09:15:51 AM CDT, Scott Marlow wrote:
Is this the safest way to fix?
Not sure what you mean by "safest" way to fix.
1. The patch is changing the serialization of Hibernate Sessions to
include the session owner. Where is org.hibernate.SessionOwner? Is
org.hibernate.SessionOwner always serializable? Could
org.hibernate.SessionOwner reference anything that could be
problematic for serialization?
If the person supplying the Session wishes it to be Serializable then
yes. That is the responsibility of the thing supplying the
SessionOwner. In most cases this is Hibernate code itself. Then main
use case being the Hibernate EntityManager as the SessionOwner. And
yes, the Hibernate EntityManagerImpl is Serializable, although perhaps
only partially iiuc (AbstractEntityManagerImpl is Serializable;
EntityManagerImpl extends AbstractEntityManagerImpl but then adds extra
state fields).
2. AbstractSessionImpl doesn't have a serialVersionUID but with
this
change to the Session serialization, I'm wondering if it should.
serialVersionUID is only ever useful in terms of attempts to ser/deser
sessions using different versions of Hibernate. That is expressly not
supported.
As for the rest of your questions, I have not looked at the code so I
cannot answer specifically.
--
steve(a)hibernate.org
http://hibernate.org
4376
days inactive
4376
days old
3 comments
3 participants
participants (3)
-
Gail Badner -
Scott Marlow -
Steve Ebersole