Re: [hibernate-dev] Temporary session and commit issue with manual flush mode
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(NativeMethodAccessorIm
[hibernate-dev] subselect mappings
subselects are a feature that was originally put in place to support databases without view support and/or application developers which did not have access to create views on their target database. I am contemplating whether we want to continue to support this. At this time I all real databases out there support views. Anyone know of any that do not? I am not inclined to leave the feature in place just for the second reason. They could always define the view in a schema in which they do have access to create views. Thoughts? -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] subselect mappings
I find the second reason important. In some organizations, the idea of developers owning a schema especially on legacy database is harder than climbing the Himalaya bare foot. Having access to the subselect views helps. I also like it for completeness since we can override insert / update / delete statements. On 20 févr. 2012, at 18:52, Steve Ebersole wrote: > subselects are a feature that was originally put in place to support > databases without view support and/or application developers which did > not have access to create views on their target database. > > I am contemplating whether we want to continue to support this. > > At this time I all real databases out there support views. Anyone know > of any that do not? > > I am not inclined to leave the feature in place just for the second > reason. They could always define the view in a schema in which they do > have access to create views. > > Thoughts? > > -- > st...@hibernate.org > http://hibernate.org > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] subselect mappings
for the "completeness" argument, the corollary to those others is actually loader, which is the ability to name a query to use for loading an entity/collection. On Mon 20 Feb 2012 12:57:36 PM CST, Emmanuel Bernard wrote: > I find the second reason important. In some organizations, the idea of > developers owning a schema especially on legacy database is harder than > climbing the Himalaya bare foot. > Having access to the subselect views helps. > > I also like it for completeness since we can override insert / update / > delete statements. > > On 20 févr. 2012, at 18:52, Steve Ebersole wrote: > >> subselects are a feature that was originally put in place to support >> databases without view support and/or application developers which did >> not have access to create views on their target database. >> >> I am contemplating whether we want to continue to support this. >> >> At this time I all real databases out there support views. Anyone know >> of any that do not? >> >> I am not inclined to leave the feature in place just for the second >> reason. They could always define the view in a schema in which they do >> have access to create views. >> >> Thoughts? >> >> -- >> st...@hibernate.org >> http://hibernate.org >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New metamodel and NamingStrategy
Grrr, of course that last line should have read:
Essentially replaces NamingStrategy#classToTableName
On Fri 17 Feb 2012 01:01:09 PM CST, Steve Ebersole wrote:
> As an example to start discussions, here is my first method proposal:
>
> public interface LogicalNamingStrategy {
> /**
> * Determine the logical table name to use for the specified entity in
> cases where the mapping did
> * not specify one explicitly.
> *
> * @param entity The entity for which to determine the table name.
> *
> * @return The table name identifier to use
> */
> public Identifier logicalTableName(Entity entity);
> }
>
> Essentially replaces NamingHelper#classToTableName
> On Fri 17 Feb 2012 12:25:37 PM CST, Steve Ebersole wrote:
>> In Austin we had discussed splitting up NamingStrategy into
>> LogicalNamingStrategy and PhysicalNamingStrategy. I am starting to
>> think though and work on that task.
>>
>> We said that the "sources" (the collective term for annotations and
>> hbm.xml) would return null to indicate that the logical naming should
>> kick in. The idea being to allow the sources to remain as true as
>> possible to the actual user supplied values.
>>
>> Anyway, just wanted to open this up to wider discussion.
>>
>> Btw the related issues are:
>> https://hibernate.onjira.com/browse/HHH-7077
>> https://hibernate.onjira.com/browse/HHH-7078
>> https://hibernate.onjira.com/browse/HHH-7079
>>
>
--
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] subselect mappings
Also, annotations currently do not support the full breadth of subselect mappings available in hbm.xml. For example, secondary tables in annotations cannot be defined using these subselecty mappings while they can in hbm.xml. If its important, it should be avilable everywhere no? On Mon 20 Feb 2012 01:09:57 PM CST, Steve Ebersole wrote: > for the "completeness" argument, the corollary to those others is > actually loader, which is the ability to name a query to use for > loading an entity/collection. > > > On Mon 20 Feb 2012 12:57:36 PM CST, Emmanuel Bernard wrote: >> I find the second reason important. In some organizations, the idea >> of developers owning a schema especially on legacy database is harder >> than climbing the Himalaya bare foot. >> Having access to the subselect views helps. >> >> I also like it for completeness since we can override insert / update >> / delete statements. >> >> On 20 févr. 2012, at 18:52, Steve Ebersole wrote: >> >>> subselects are a feature that was originally put in place to support >>> databases without view support and/or application developers which did >>> not have access to create views on their target database. >>> >>> I am contemplating whether we want to continue to support this. >>> >>> At this time I all real databases out there support views. Anyone know >>> of any that do not? >>> >>> I am not inclined to leave the feature in place just for the second >>> reason. They could always define the view in a schema in which they do >>> have access to create views. >>> >>> Thoughts? >>> >>> -- >>> st...@hibernate.org >>> http://hibernate.org >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Temporary session and commit issue with manual flush mode
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 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] subselect mappings
Another subselect usage that does not currently appear to be supported in annotations is for collection mappings. In hbm.xml you can specify a subselect as the table for collections. On Mon 20 Feb 2012 01:21:35 PM CST, Steve Ebersole wrote: > Also, annotations currently do not support the full breadth of > subselect mappings available in hbm.xml. > > For example, secondary tables in annotations cannot be defined using > these subselecty mappings while they can in hbm.xml. If its important, > it should be avilable everywhere no? > > On Mon 20 Feb 2012 01:09:57 PM CST, Steve Ebersole wrote: >> for the "completeness" argument, the corollary to those others is >> actually loader, which is the ability to name a query to use for >> loading an entity/collection. >> >> >> On Mon 20 Feb 2012 12:57:36 PM CST, Emmanuel Bernard wrote: >>> I find the second reason important. In some organizations, the idea >>> of developers owning a schema especially on legacy database is >>> harder than climbing the Himalaya bare foot. >>> Having access to the subselect views helps. >>> >>> I also like it for completeness since we can override insert / >>> update / delete statements. >>> >>> On 20 févr. 2012, at 18:52, Steve Ebersole wrote: >>> subselects are a feature that was originally put in place to support databases without view support and/or application developers which did not have access to create views on their target database. I am contemplating whether we want to continue to support this. At this time I all real databases out there support views. Anyone know of any that do not? I am not inclined to leave the feature in place just for the second reason. They could always define the view in a schema in which they do have access to create views. Thoughts? -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
