4:40 a.m.
Hi all,
I have a question regarding SessionFactoryImplementor.openTemporarySession() (bug
HHH-7017). As observed in non JTA environment
with manual flush mode enabled, and 'hibernate.connection.autocommit' disabled,
temporary session is not getting committed.
How/when should I commit it manually? According to JavaDoc, it's
"nontransactional". See the following log (H2):
11:19:01,531 DEBUG SQL:104 - insert into StrTestEntity_AUD (REVTYPE, str, id, REV) values
(?, ?, ?, ?)
11:19:03,687 WARN SqlExceptionHelper:143 - SQL Error: 50200, SQLState: HYT00
Timeout trying to lock table "STRTESTENTITY_AUD"; SQL statement:
select strtestent0_.REV as col_0_0_ from StrTestEntity_AUD strtestent0_ cross join REVINFO
defaultrev1_ where strtestent0_.id=?
and strtestent0_.REV=defaultrev1_.REV order by strtestent0_.REV asc [50200-145]
at
org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:52)
...
Method AuditProcess.doBeforeTransactionCompletion() is responsible for persisting all
audit data. The description in HHH-7017 is
very accurate and correct. Please advice.
How is temporary session related to current normal session and its lifecycle?
Regards,
Lukasz
5:28 p.m.
Probably openTemporarySession() should be deprecated. Notice it also
says it is for HEM use, though the only current uses I see of it all
come from envers.
If you want to share information from the main session, then the
appropriate access would be to use org.hibernate.SharedSessionBuilder as
obtained from org.hibernate.Session#sessionWithOptions
If the 2 should share JDBC connection, then
org.hibernate.SharedSessionBuilder#connection() should be used. If you
want it to share the entire "transaction context", then
org.hibernate.SharedSessionBuilder#transactionContext() should be used.
Pretty sure I asked Adam and the rest of the list about this
transactionContext() method back when I first added it. I never heard
any response. So if you go that transactionContext() route you may run
into issues because I am pretty sure transactionContext() is sharing too
much.
On 02/12/2012 04:40 AM, Łukasz Antoniak wrote:
Hi all,
I have a question regarding SessionFactoryImplementor.openTemporarySession() (bug
HHH-7017). As observed in non JTA environment
with manual flush mode enabled, and 'hibernate.connection.autocommit' disabled,
temporary session is not getting committed.
How/when should I commit it manually? According to JavaDoc, it's
"nontransactional". See the following log (H2):
11:19:01,531 DEBUG SQL:104 - insert into StrTestEntity_AUD (REVTYPE, str, id, REV) values
(?, ?, ?, ?)
11:19:03,687 WARN SqlExceptionHelper:143 - SQL Error: 50200, SQLState: HYT00
Timeout trying to lock table "STRTESTENTITY_AUD"; SQL statement:
select strtestent0_.REV as col_0_0_ from StrTestEntity_AUD strtestent0_ cross join
REVINFO defaultrev1_ where strtestent0_.id=?
and strtestent0_.REV=defaultrev1_.REV order by strtestent0_.REV asc [50200-145]
at
org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:52)
...
Method AuditProcess.doBeforeTransactionCompletion() is responsible for persisting all
audit data. The description in HHH-7017 is
very accurate and correct. Please advice.
How is temporary session related to current normal session and its lifecycle?
Regards,
Lukasz
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
steve(a)hibernate.org
http://hibernate.org
2:42 p.m.
Thanks Steve for such a descriptive replay. I have played a little with SessionBuilder and
probably solved the issue. Because of
great importance of AuditProcess#doBeforeTransactionCompletion(SessionImplementor) method,
please verify my commit:
https://github.com/lukasz-antoniak/hibernate-core/commit/e6aaa49dcc847e56....
Tell me if it makes sense from
your perspective.
Regards,
Lukasz
2:59 p.m.
In general, yes, this is what I meant.
I think on_close or after_transaction might be better connection
release mode here.
Also, I would personally be more inclined to close the "temp session"
manually there in that block. But that part is really just a
preference I think.
On Mon 13 Feb 2012 02:42:07 PM CST, Łukasz Antoniak wrote:
Thanks Steve for such a descriptive replay. I have played a little
with SessionBuilder and probably solved the issue. Because of great
importance of
AuditProcess#doBeforeTransactionCompletion(SessionImplementor) method,
please verify my commit:
https://github.com/lukasz-antoniak/hibernate-core/commit/e6aaa49dcc847e56....
Tell me if it makes sense from your perspective.
Regards,
Lukasz
--
steve(a)hibernate.org
http://hibernate.org
4:42 a.m.
Yes, I also think the session should be closed after being used, otherwise you start
wondering why it's not being closed (as I did looking at the code) :)
Adam
On Feb 13, 2012, at 9:59 PM, Steve Ebersole wrote:
In general, yes, this is what I meant.
I think on_close or after_transaction might be better connection
release mode here.
Also, I would personally be more inclined to close the "temp session"
manually there in that block. But that part is really just a
preference I think.
On Mon 13 Feb 2012 02:42:07 PM CST, Łukasz Antoniak wrote:
> Thanks Steve for such a descriptive replay. I have played a little
> with SessionBuilder and probably solved the issue. Because of great
> importance of
> AuditProcess#doBeforeTransactionCompletion(SessionImplementor) method,
> please verify my commit:
>
https://github.com/lukasz-antoniak/hibernate-core/commit/e6aaa49dcc847e56....
> Tell me if it makes sense from your perspective.
>
> Regards,
> Lukasz
--
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
--
Adam Warski
http://twitter.com/#!/adamwarski
http://www.softwaremill.com
http://www.warski.org
1:27 a.m.
I totally agree with you guys :). However, when I do something like:
if (FlushMode.isManualFlushMode(session.getFlushMode())) {
Session temporarySession = null;
try {
temporarySession = ((Session) session).sessionWithOptions().transactionContext()
.connectionReleaseMode(ConnectionReleaseMode.AFTER_TRANSACTION)
.openSession();
executeInSession(temporarySession);
temporarySession.flush();
} finally {
if (temporarySession != null) {
temporarySession.close();
}
}
} else {
I receive an exception:
08:20:40,296 DEBUG SQL:104 - insert into StrTestEntity (id, str) values (null, ?)
08:20:40,359 DEBUG SQL:104 - insert into REVINFO (REV, REVTSTMP) values (null, ?)
08:20:40,375 DEBUG SQL:104 - insert into StrTestEntity_AUD (REVTYPE, str, id, REV) values
(?, ?, ?, ?)
javax.persistence.PersistenceException: org.hibernate.ResourceClosedException: This
TransactionCoordinator has been closed
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1360)
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1288)
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1370)
at org.hibernate.ejb.TransactionImpl.begin(TransactionImpl.java:60)
at org.hibernate.envers.test.integration.flush.ManualFlush.initData(ManualFlush.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:63)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.hibernate.testing.junit4.FailureExpectedHandler.evaluate(FailureExpectedHandler.java:59)
at
org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at
org.hibernate.testing.junit4.BeforeClassCallbackHandler.evaluate(BeforeClassCallbackHandler.java:43)
at
org.hibernate.testing.junit4.AfterClassCallbackHandler.evaluate(AfterClassCallbackHandler.java:42)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:94)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:192)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115)
Caused by: org.hibernate.ResourceClosedException: This TransactionCoordinator has been
closed
at
org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl.getTransaction(TransactionCoordinatorImpl.java:186)
at org.hibernate.internal.SessionImpl.getTransaction(SessionImpl.java:1303)
at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1308)
at org.hibernate.ejb.TransactionImpl.begin(TransactionImpl.java:57)
... 40 more
Without explicitly closing the temporary session and autoClose option turned on everything
works as expected.
Regards,
Lukasz
8:29 a.m.
Well these are the kind of details I was asking about with
transactionContext() :)
So transactionContext() is sharing too much of itself at the moment to
use it this way. Currently it just shares the entire
org.hibernate.engine.transaction.spi.TransactionContext from the
originating Session. When the "subordinate" Session is closed it is
closing that shared TransactionContext. Later when the originating
Session tries to access it we have problems.
The main question is whether we should change this up in point release.
Or just keep it as-is since y'all have a working approach anyway
On Sat 18 Feb 2012 01:27:26 AM CST, Łukasz Antoniak wrote:
I totally agree with you guys :). However, when I do something like:
if (FlushMode.isManualFlushMode(session.getFlushMode())) {
Session temporarySession = null;
try {
temporarySession = ((Session)
session).sessionWithOptions().transactionContext()
.connectionReleaseMode(ConnectionReleaseMode.AFTER_TRANSACTION)
.openSession();
executeInSession(temporarySession);
temporarySession.flush();
} finally {
if (temporarySession != null) {
temporarySession.close();
}
}
} else {
I receive an exception:
08:20:40,296 DEBUG SQL:104 - insert into StrTestEntity (id, str)
values (null, ?)
08:20:40,359 DEBUG SQL:104 - insert into REVINFO (REV, REVTSTMP)
values (null, ?)
08:20:40,375 DEBUG SQL:104 - insert into StrTestEntity_AUD (REVTYPE,
str, id, REV) values (?, ?, ?, ?)
javax.persistence.PersistenceException:
org.hibernate.ResourceClosedException: This TransactionCoordinator has
been closed
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1360)
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1288)
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1370)
at org.hibernate.ejb.TransactionImpl.begin(TransactionImpl.java:60)
at
org.hibernate.envers.test.integration.flush.ManualFlush.initData(ManualFlush.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:63)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.hibernate.testing.junit4.FailureExpectedHandler.evaluate(FailureExpectedHandler.java:59)
at
org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at
org.hibernate.testing.junit4.BeforeClassCallbackHandler.evaluate(BeforeClassCallbackHandler.java:43)
at
org.hibernate.testing.junit4.AfterClassCallbackHandler.evaluate(AfterClassCallbackHandler.java:42)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:94)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:192)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115)
Caused by: org.hibernate.ResourceClosedException: This
TransactionCoordinator has been closed
at
org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl.getTransaction(TransactionCoordinatorImpl.java:186)
at
org.hibernate.internal.SessionImpl.getTransaction(SessionImpl.java:1303)
at
org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1308)
at org.hibernate.ejb.TransactionImpl.begin(TransactionImpl.java:57)
... 40 more
Without explicitly closing the temporary session and autoClose option
turned on everything works as expected.
Regards,
Lukasz
--
steve(a)hibernate.org
http://hibernate.org
3:05 p.m.
Steve, I have created a JIRA issue (https://hibernate.onjira.com/browse/HHH-7090) and
assigned it to you. Why do you think that we
should not fix this in the upcoming release? I have also noticed that auto-closing feature
of SharedSessionBuilder does not work
as documented in JavaDoc. Please see test case attached to JIRA issue. This prevents me
from fixing HHH-7017; temporary session is
still opened. Am I wrong?
Regards,
Lukasz
4:41 a.m.
Probably openTemporarySession() should be deprecated. Notice it also
says it is for HEM use, though the only current uses I see of it all
come from envers.
Right, I was never happy using it, but I don't think there were other options at that
time. Or I just couldn't find them.
Pretty sure I asked Adam and the rest of the list about this
transactionContext() method back when I first added it. I never heard
any response. So if you go that transactionContext() route you may run
into issues because I am pretty sure transactionContext() is sharing too
much.
I must have missed that somehow, sorry.
--
Adam Warski
http://twitter.com/#!/adamwarski
http://www.softwaremill.com
http://www.warski.org
5069
days inactive
5077
days old
8 comments
3 participants
participants (3)
-
Adam Warski -
Steve Ebersole -
Łukasz Antoniak