Menu
▾
▴
hibernate-issues — Hibernate JIRA Notifications
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(175) |
Jul
(209) |
Aug
(302) |
Sep
(287) |
Oct
(339) |
Nov
(314) |
Dec
(329) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(479) |
Feb
(389) |
Mar
(599) |
Apr
(307) |
May
(390) |
Jun
(300) |
Jul
(410) |
Aug
(458) |
Sep
(299) |
Oct
(315) |
Nov
(363) |
Dec
(529) |
| 2005 |
Jan
(568) |
Feb
(434) |
Mar
(1004) |
Apr
(823) |
May
(767) |
Jun
(763) |
Jul
(854) |
Aug
(862) |
Sep
(560) |
Oct
(853) |
Nov
(763) |
Dec
(731) |
| 2006 |
Jan
(776) |
Feb
(608) |
Mar
(657) |
Apr
(424) |
May
(559) |
Jun
(440) |
Jul
(448) |
Aug
(58) |
Sep
|
Oct
(17) |
Nov
(16) |
Dec
(8) |
| 2007 |
Jan
(1) |
Feb
(8) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(16) |
Sep
(10) |
Oct
(4) |
Nov
(4) |
Dec
(4) |
| 2008 |
Jan
(8) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Lionel (JIRA) <no...@at...> - 2006-05-19 15:28:11
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1700?page=comments#action_23134 ] Lionel commented on HHH-1700: ----------------------------- Hi ! I need this too !! It would be very usefull. Your idea works nearly fine, the only problem is that you add the alias in the group by clause The sql generated looks like this: select count(id), xxx as myAlias from table group by xxx as myAlias having count(...)>0 Simply use another StringBuffer without the alias to specify the groupBy. Tested on Hibernate 3.0.5 / Oracle 10g > HAVING clause not supported in Criteria API > ------------------------------------------- > > Key: HHH-1700 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1700 > Project: Hibernate3 > Type: New Feature > Components: query-criteria > Versions: 3.1.3 > Environment: Hibernate 3.1.3, Oracle 10g (not DB specific) > Reporter: Manuel Dominguez Sarmiento > Priority: Minor > Attachments: CustomProjections.java > > Original Estimate: 2 hours > Remaining: 2 hours > > Currently the Criteria API does not support the HAVING clause. I have create a factory class which creates Projection instances using sqlGroupProjection. Probably not the best approach, but an idea which could be further developed. These factory methods could be included in the Projections factory class. > Usage example w/one property: > criteria.setProjection(CustomProjections.groupByHaving("id", Hibernate.LONG, "count(distinct id) >= 3")); > Also allows aliases: > criteria.setProjection(CustomProjections.groupByHaving("id", "idAlias", Hibernate.LONG, "count(distinct idAlias) >= 3")); > Usage example w/many properties: > String[] columns = new String[2]; > columns[0] = "id"; > columns[1] = "name"; > String[] aliases = new String[2]; > aliases[0] = "idAlias"; > aliases[1] = "nameAlias"; > Type[] types = new Type[2]; > types[0] = Hibernate.LONG; > types[1] = Hibernate.STRING; > criteria.setProjection(CustomProjections.groupByHaving(columns, aliases, types, "count(distinct id) >= 3 and name='george'")); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: <no...@at...> - 2006-05-19 15:03:28
|
NullPointerException when try to session after commit
-----------------------------------------------------
Key: HHH-1769
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH=
-1769
Project: Hibernate3
Type: Bug
Versions: 3.1 rc3 =20
Environment: postgresql8, jboss4.0.3SP1, unix (linux, os x)
Reporter: C=C3=A9dric Chantepie
When trying to get entity by "load" on hibernate session, just after having=
commit underlying transaction, and before closing session, a NullPointerEx=
ception is thrown from Batcher (AbstractBatcher, BatchingBatcher) as connec=
tionManager return a null connection so method "prepareQueryStatement" in t=
his batcher cannot work.
It seems ok that it should not work after commit but I think a more explici=
t exception should be provided in order to make debug more easy.
---
hsession.saveOrUpdate(test);
tx.commit();
Test tsaved =3D hsession.load(Test.class, "pk"); // NullPointerException ra=
ises here
hsession.close();
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators=
.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Jarkko L. (JIRA) <no...@at...> - 2006-05-19 11:57:11
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-664?page=comments#action_23133 ] Jarkko Lietolahti commented on HBX-664: --------------------------------------- i was thinking it might no be that clear ;) Yes, this is seam specifc (as the real change is in the seam template). The case is that when DefaultReverseEngineeringStrategy (foreignKeyToCollectionName() ) creates collections is uses ReverseEngineeringStrategyUtil.simplePluralize to name the getter-method in the entity. Now in the seam template the old way was simply to add "s" when calling the entitys getter. Compared to simplePluralize which uses weird english-only heuristic to determine the name. instance.${getter}().get${pojo.shortName}s().remove(instance); ReverseEngineeringStrategyUtil.java ... static public String simplePluralize(String singular) { char last = singular.charAt( singular.length()-1 ); switch (last) { case 'x': case 's': singular += "es"; break; case 'y': singular = singular.substring( 0, singular.length()-1 ) + "ies"; break; default: singular += "s"; } return singular; } btw, just noticed that the patch contains few things which are not related to this issue (but to an other one which is that the messages.properties is not initialized properly): - @${pojo.importType("org.jboss.seam.annotations.In")} + @${pojo.importType("org.jboss.seam.annotations.In")}(create=true) Those lines can be removed from the patch. > Patch to allow reverse engineering to work with tables and associations ending with "s" > ---------------------------------------------------------------------------------------- > > Key: HBX-664 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-664 > Project: Hibernate Tools > Type: Patch > Components: reverse-engineer > Versions: 3.1.beta5 > Reporter: Jarkko Lietolahti > > > Index: java/org/hibernate/tool/hbm2x/pojo/BasicPOJOClass.java > =================================================================== > --- java/org/hibernate/tool/hbm2x/pojo/BasicPOJOClass.java (revision 9925) > +++ java/org/hibernate/tool/hbm2x/pojo/BasicPOJOClass.java (working copy) > @@ -86,6 +86,10 @@ > return StringHelper.unqualify(getMappedClassName()); > } > > + public String getShortNamePlural() { > + return ReverseEngineeringStrategyUtil.simplePluralize(getShortName()); > + } > + > public String getQualifiedDeclarationName() { > String generatedName = getMetaAsString( MetaAttributeConstants.GENERATED_CLASS ); > if ( generatedName == null || generatedName.trim().length() == 0 ) { > Index: java/org/hibernate/tool/hbm2x/pojo/POJOClass.java > =================================================================== > --- java/org/hibernate/tool/hbm2x/pojo/POJOClass.java (revision 9925) > +++ java/org/hibernate/tool/hbm2x/pojo/POJOClass.java (working copy) > @@ -74,7 +74,8 @@ > > public String getPackageName(); > public String getShortName(); > - > + public String getShortNamePlural(); > + > public Iterator getToStringPropertiesIterator(); > public Iterator getEqualsHashCodePropertiesIterator(); > > Index: templates/seam/editorbean.java.ftl > =================================================================== > --- templates/seam/editorbean.java.ftl (revision 9925) > +++ templates/seam/editorbean.java.ftl (working copy) > @@ -1,5 +1,5 @@ > ${pojo.getPackageDeclaration()} > -// Generated ${date} by Hibernate Tools ${version} > +// Generated ${date} by Hibernate Tools ${version}-jab > > <#assign classbody> > <#assign entityEditor = pojo.shortName.toLowerCase() + "Editor"><#assign entityFinder = pojo.shortName.toLowerCase() + "Finder"><#assign entityList = pojo.shortName.toLowerCase() + "List"><#assign entity = pojo.shortName.toLowerCase()><#assign entityClass = pojo.importType(pojo.qualifiedDeclarationName)> > @@ -38,7 +38,7 @@ > @${pojo.importType("org.jboss.seam.annotations.In")}(required=false) > private transient ${pojo.shortName}Finder ${entityFinder}; > > - @${pojo.importType("org.jboss.seam.annotations.In")} > + @${pojo.importType("org.jboss.seam.annotations.In")}(create=true) > private transient ${pojo.importType("java.util.ResourceBundle")} resourceBundle; > > @${pojo.importType("org.jboss.seam.annotations.Begin")}(join=true) > @@ -57,7 +57,7 @@ > </#if> entityManager.persist(instance); > isNew = false; > <#foreach property in pojo.getAllPropertiesIterator()><#if c2h.isManyToOne(property)><#assign getter = "get" + pojo.getPropertyName(property)> if (instance.${getter}()!=null) { > - instance.${getter}().get${pojo.shortName}s().add(instance); > + instance.${getter}().get${pojo.shortNamePlural}().add(instance); > } > </#if></#foreach> refreshFinder(); > return "edit${pojo.shortName}"; > @@ -72,7 +72,8 @@ > @${pojo.importType("org.jboss.seam.annotations.End")}(ifOutcome="find") > public String delete() { > entityManager.remove(instance); > -<#foreach property in pojo.getAllPropertiesIterator()><#if c2h.isManyToOne(property)><#assign getter = "get" + pojo.getPropertyName(property)> instance.${getter}().get${pojo.shortName}s().remove(instance); > +<#foreach property in pojo.getAllPropertiesIterator()><#if c2h.isManyToOne(property)><#assign getter = "get" + pojo.getPropertyName(property)> > + instance.${getter}().get${pojo.shortNamePlural}().remove(instance); > </#if></#foreach> refreshFinder(); > return doneOutcome; > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Max R. A. (JIRA) <no...@at...> - 2006-05-19 11:44:17
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-664?page=comments#action_23132 ] Max Rydahl Andersen commented on HBX-664: ----------------------------------------- thanks - but what does this patch actually fix ? the reverse engineering works fine with everything so I assume it is something seam template specific....maybe you have a testcase? > Patch to allow reverse engineering to work with tables and associations ending with "s" > ---------------------------------------------------------------------------------------- > > Key: HBX-664 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-664 > Project: Hibernate Tools > Type: Patch > Components: reverse-engineer > Versions: 3.1.beta5 > Reporter: Jarkko Lietolahti > > > Index: java/org/hibernate/tool/hbm2x/pojo/BasicPOJOClass.java > =================================================================== > --- java/org/hibernate/tool/hbm2x/pojo/BasicPOJOClass.java (revision 9925) > +++ java/org/hibernate/tool/hbm2x/pojo/BasicPOJOClass.java (working copy) > @@ -86,6 +86,10 @@ > return StringHelper.unqualify(getMappedClassName()); > } > > + public String getShortNamePlural() { > + return ReverseEngineeringStrategyUtil.simplePluralize(getShortName()); > + } > + > public String getQualifiedDeclarationName() { > String generatedName = getMetaAsString( MetaAttributeConstants.GENERATED_CLASS ); > if ( generatedName == null || generatedName.trim().length() == 0 ) { > Index: java/org/hibernate/tool/hbm2x/pojo/POJOClass.java > =================================================================== > --- java/org/hibernate/tool/hbm2x/pojo/POJOClass.java (revision 9925) > +++ java/org/hibernate/tool/hbm2x/pojo/POJOClass.java (working copy) > @@ -74,7 +74,8 @@ > > public String getPackageName(); > public String getShortName(); > - > + public String getShortNamePlural(); > + > public Iterator getToStringPropertiesIterator(); > public Iterator getEqualsHashCodePropertiesIterator(); > > Index: templates/seam/editorbean.java.ftl > =================================================================== > --- templates/seam/editorbean.java.ftl (revision 9925) > +++ templates/seam/editorbean.java.ftl (working copy) > @@ -1,5 +1,5 @@ > ${pojo.getPackageDeclaration()} > -// Generated ${date} by Hibernate Tools ${version} > +// Generated ${date} by Hibernate Tools ${version}-jab > > <#assign classbody> > <#assign entityEditor = pojo.shortName.toLowerCase() + "Editor"><#assign entityFinder = pojo.shortName.toLowerCase() + "Finder"><#assign entityList = pojo.shortName.toLowerCase() + "List"><#assign entity = pojo.shortName.toLowerCase()><#assign entityClass = pojo.importType(pojo.qualifiedDeclarationName)> > @@ -38,7 +38,7 @@ > @${pojo.importType("org.jboss.seam.annotations.In")}(required=false) > private transient ${pojo.shortName}Finder ${entityFinder}; > > - @${pojo.importType("org.jboss.seam.annotations.In")} > + @${pojo.importType("org.jboss.seam.annotations.In")}(create=true) > private transient ${pojo.importType("java.util.ResourceBundle")} resourceBundle; > > @${pojo.importType("org.jboss.seam.annotations.Begin")}(join=true) > @@ -57,7 +57,7 @@ > </#if> entityManager.persist(instance); > isNew = false; > <#foreach property in pojo.getAllPropertiesIterator()><#if c2h.isManyToOne(property)><#assign getter = "get" + pojo.getPropertyName(property)> if (instance.${getter}()!=null) { > - instance.${getter}().get${pojo.shortName}s().add(instance); > + instance.${getter}().get${pojo.shortNamePlural}().add(instance); > } > </#if></#foreach> refreshFinder(); > return "edit${pojo.shortName}"; > @@ -72,7 +72,8 @@ > @${pojo.importType("org.jboss.seam.annotations.End")}(ifOutcome="find") > public String delete() { > entityManager.remove(instance); > -<#foreach property in pojo.getAllPropertiesIterator()><#if c2h.isManyToOne(property)><#assign getter = "get" + pojo.getPropertyName(property)> instance.${getter}().get${pojo.shortName}s().remove(instance); > +<#foreach property in pojo.getAllPropertiesIterator()><#if c2h.isManyToOne(property)><#assign getter = "get" + pojo.getPropertyName(property)> > + instance.${getter}().get${pojo.shortNamePlural}().remove(instance); > </#if></#foreach> refreshFinder(); > return doneOutcome; > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: jose (JIRA) <no...@at...> - 2006-05-19 11:22:17
|
Sybase and empty varchars
-------------------------
Key: HHH-1768
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1768
Project: Hibernate3
Type: Bug
Reporter: jose
In sybase
an insert/update operation with empty ('') varchar column its replaced with one empty space (' ')
then any HQL returns the empty space -> incorrect
In hibernate2 this not occurs, its a missing feature? new bug?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Jarkko L. (JIRA) <no...@at...> - 2006-05-19 10:43:21
|
Patch to allow reverse engineering to work with tables and associations ending with "s"
----------------------------------------------------------------------------------------
Key: HBX-664
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-664
Project: Hibernate Tools
Type: Patch
Components: reverse-engineer
Versions: 3.1.beta5
Reporter: Jarkko Lietolahti
Index: java/org/hibernate/tool/hbm2x/pojo/BasicPOJOClass.java
===================================================================
--- java/org/hibernate/tool/hbm2x/pojo/BasicPOJOClass.java (revision 9925)
+++ java/org/hibernate/tool/hbm2x/pojo/BasicPOJOClass.java (working copy)
@@ -86,6 +86,10 @@
return StringHelper.unqualify(getMappedClassName());
}
+ public String getShortNamePlural() {
+ return ReverseEngineeringStrategyUtil.simplePluralize(getShortName());
+ }
+
public String getQualifiedDeclarationName() {
String generatedName = getMetaAsString( MetaAttributeConstants.GENERATED_CLASS );
if ( generatedName == null || generatedName.trim().length() == 0 ) {
Index: java/org/hibernate/tool/hbm2x/pojo/POJOClass.java
===================================================================
--- java/org/hibernate/tool/hbm2x/pojo/POJOClass.java (revision 9925)
+++ java/org/hibernate/tool/hbm2x/pojo/POJOClass.java (working copy)
@@ -74,7 +74,8 @@
public String getPackageName();
public String getShortName();
-
+ public String getShortNamePlural();
+
public Iterator getToStringPropertiesIterator();
public Iterator getEqualsHashCodePropertiesIterator();
Index: templates/seam/editorbean.java.ftl
===================================================================
--- templates/seam/editorbean.java.ftl (revision 9925)
+++ templates/seam/editorbean.java.ftl (working copy)
@@ -1,5 +1,5 @@
${pojo.getPackageDeclaration()}
-// Generated ${date} by Hibernate Tools ${version}
+// Generated ${date} by Hibernate Tools ${version}-jab
<#assign classbody>
<#assign entityEditor = pojo.shortName.toLowerCase() + "Editor"><#assign entityFinder = pojo.shortName.toLowerCase() + "Finder"><#assign entityList = pojo.shortName.toLowerCase() + "List"><#assign entity = pojo.shortName.toLowerCase()><#assign entityClass = pojo.importType(pojo.qualifiedDeclarationName)>
@@ -38,7 +38,7 @@
@${pojo.importType("org.jboss.seam.annotations.In")}(required=false)
private transient ${pojo.shortName}Finder ${entityFinder};
- @${pojo.importType("org.jboss.seam.annotations.In")}
+ @${pojo.importType("org.jboss.seam.annotations.In")}(create=true)
private transient ${pojo.importType("java.util.ResourceBundle")} resourceBundle;
@${pojo.importType("org.jboss.seam.annotations.Begin")}(join=true)
@@ -57,7 +57,7 @@
</#if> entityManager.persist(instance);
isNew = false;
<#foreach property in pojo.getAllPropertiesIterator()><#if c2h.isManyToOne(property)><#assign getter = "get" + pojo.getPropertyName(property)> if (instance.${getter}()!=null) {
- instance.${getter}().get${pojo.shortName}s().add(instance);
+ instance.${getter}().get${pojo.shortNamePlural}().add(instance);
}
</#if></#foreach> refreshFinder();
return "edit${pojo.shortName}";
@@ -72,7 +72,8 @@
@${pojo.importType("org.jboss.seam.annotations.End")}(ifOutcome="find")
public String delete() {
entityManager.remove(instance);
-<#foreach property in pojo.getAllPropertiesIterator()><#if c2h.isManyToOne(property)><#assign getter = "get" + pojo.getPropertyName(property)> instance.${getter}().get${pojo.shortName}s().remove(instance);
+<#foreach property in pojo.getAllPropertiesIterator()><#if c2h.isManyToOne(property)><#assign getter = "get" + pojo.getPropertyName(property)>
+ instance.${getter}().get${pojo.shortNamePlural}().remove(instance);
</#if></#foreach> refreshFinder();
return doneOutcome;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Christian B. (JIRA) <no...@at...> - 2006-05-19 07:19:16
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1757?page=comments#action_23131 ] Christian Bauer commented on HHH-1757: -------------------------------------- Documented this... > "Named query not known" with valid <query>. Invalid hibernate-mapping-3.0.dtd > ------------------------------------------------------------------------------ > > Key: HHH-1757 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1757 > Project: Hibernate3 > Type: Bug > Versions: 3.1.3 > Environment: Hibernate v3.1.3, MySQL v5.0.21, jdk1.5.0_06 > Reporter: W. Muir > Priority: Minor > > > <query> element in a hibernate mapping file validates against the DTD (http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd) for both cases: > Case 1: <query> element outside <class> > <hibernate-mapping> > <class name="com.acme.Foo" table="foo"> > ... > </class> > <query name="Foo.findBy"> > <![CDATA[ FROM Foo WHERE ... ]]> > </query> > </hibernate-mapping> > Case 2: <query> element inside <class> > <hibernate-mapping> > <class name="com.acme.Foo" table="foo"> > ... > <query name="Foo.findBy"> > <![CDATA[ FROM Foo WHERE ... ]]> > </query> > </class> > </hibernate-mapping> > However, Case 2 produces a Mapping Exception: > > org.hibernate.MappingException: Named query not known: Foo.findBy > when session.getNamedQuery( "Foo.findBy" ) is called. > If the the exception caused by Case #2 is legit, then the DTD should be changed so mapping xml will not validate when <query> is within <class> element. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Jaka J. (JIRA) <no...@at...> - 2006-05-19 03:34:21
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1764?page=comments#action_23130 ] Jaka Jaksic commented on HHH-1764: ---------------------------------- This might also be a bug in JBossCache. According to this page: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheOptionsAPI , the failSilently option, which Hibernate does use in this place, should also have the effect of cache bypassing the transaction, but this just doesn't happen -- cache invalidation still happens within JTA transaction and an exception occurs. I posted this on the JBossCache forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3944813#3944813 > Cache invalidation in OptimisticTreeCache conflicts with JTA transactions > ------------------------------------------------------------------------- > > Key: HHH-1764 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1764 > Project: Hibernate3 > Type: Patch > Components: core > Versions: 3.2.0.cr2 > Environment: Hibernate 3.1.3 with added OptimisticTreeCache classes from 3.2.0.cr2, JBoss Cache 1.3 SP2, JBoss 4.0.3 SP1, PostgreSQL 8.1.2 > Reporter: Jaka Jaksic > Attachments: OptimisticTreeCache.patch > > Original Estimate: 10 minutes > Remaining: 10 minutes > > After switching to Hibernate 3.2.0.cr2's OptimisticTreeCache, exceptions started to occur after every commit. The reason is that, unlike TreeCache, OptimisticTreeCache doesn't perform cache invalidation _outside_ the scope of JTA transaction, even though the comment in its put() method states so... So because cache invalidation happens after commit, when the tx status is set to 3 (STATUS_COMMITTED), which TreeCache finds invalid, the following exception occurs: > 00:53:51,754 WARN [TreeCache] status is 3 (not ACTIVE or PREPARING); returning null) > 00:53:51,754 INFO [TxInterceptor] There was a problem handling this request org.jboss.cache.CacheException: Must be in a valid transaction _put(null, /org/hibernate/cache/UpdateTimestampsCache/EVENT_LOG, item, 11479064317, true) > The original TreeCache properly bypasses JTA transaction by calling suspend(). I don't know why OptimisticTreeCache doesn't do that as well. I just copied that code from the TreeCache class and it seems to work well. > If there is a reason why OptimisticTreeCache should not do it this way, please let me know what it is and how to solve this problem properly. Otherwise just use the provided patch. > Here's the full stack trace: > 00:53:51,754 WARN [TreeCache] status is 3 (not ACTIVE or PREPARING); returning null) > 00:53:51,754 INFO [TxInterceptor] There was a problem handling this request org.jboss.cache.CacheException: Must be in a valid transaction _put(null, /org/hibernate/cache/UpdateTimestampsCache/EVENT_LOG, item, 11479064317, true) > at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:113) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) > at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:68) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) > at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:76) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) > at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:116) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) > at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:328) > at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:139) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) > at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:153) > at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:4804) > at org.jboss.cache.TreeCache.put(TreeCache.java:3242) > at org.jboss.cache.TreeCache.put(TreeCache.java:2937) > at org.hibernate.cache.OptimisticTreeCache.put(OptimisticTreeCache.java:139) > at org.hibernate.cache.UpdateTimestampsCache.invalidate(UpdateTimestampsCache.java:67) > at org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:174) > at org.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:419) > at org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(JDBCContext.java:209) > at org.hibernate.transaction.CacheSynchronization.afterCompletion(CacheSynchronization.java:85) > at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1508) > at org.jboss.tm.TransactionImpl.completeTransaction(TransactionImpl.java:1180) > at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:359) > at org.jboss.tm.TxManager.commit(TxManager.java:224) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:126) > at org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:146) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Martin S. (JIRA) <no...@at...> - 2006-05-19 00:33:22
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-227?page=comments#action_23129 ] Martin Schulz commented on HHH-227: ----------------------------------- Sould also change etc/hibernate.properties as per the following patch (note the forgotten name change of hte property!!): $ diff -u etc/hibernate.properties.bak etc/hibernate.properties --- etc/hibernate.properties.bak 2006-05-18 20:26:46.000000000 -0400 +++ etc/hibernate.properties 2006-05-18 20:27:20.000000000 -0400 @@ -357,9 +357,9 @@ #hibernate.use_identifer_rollback true -## enable CGLIB reflection optimizer (enabled by default) +## enable CGLIB reflection optimizer (disabled by default) -#hibernate.cglib.use_reflection_optimizer false +#hibernate.cglib.use_reflection_optimizer true > remove reflection optimizer > --------------------------- > > Key: HHH-227 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-227 > Project: Hibernate3 > Type: Improvement > Components: core > Reporter: Juozas Baliuka > Assignee: amit bhayani > Priority: Minor > Fix For: 3.2.0 cr1 > Attachments: Environment.java > > > Probably it is a good time to drop "reflection_optimizer" (or to dissable it by default), SUN JVM generates code since jdk 1.4.2 to optimize native calls in reflection itself, double code generation just wastes memory (cglib is bit faster, but difference is too trivial to be usefull for data access). > This stuff confuses users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-05-18 22:38:16
|
Support @Filter when an association table is involved
-----------------------------------------------------
Key: ANN-346
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-346
Project: Hibernate Annotations
Type: Improvement
Components: binder
Reporter: Emmanuel Bernard
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-05-18 22:29:17
|
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-345?page=all ] Emmanuel Bernard resolved ANN-345: ---------------------------------- Resolution: Fixed > EJB3NamingStrategy should be Serializable > ----------------------------------------- > > Key: ANN-345 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-345 > Project: Hibernate Annotations > Type: Bug > Components: binder > Versions: 3.2.0.cr1 > Reporter: Emmanuel Bernard > Assignee: Emmanuel Bernard > Priority: Trivial > Fix For: 3.2.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-05-18 22:27:14
|
EJB3NamingStrategy should be Serializable
-----------------------------------------
Key: ANN-345
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-345
Project: Hibernate Annotations
Type: Bug
Components: binder
Versions: 3.2.0.cr1
Reporter: Emmanuel Bernard
Assigned to: Emmanuel Bernard
Priority: Trivial
Fix For: 3.2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Alex B. (JIRA) <no...@at...> - 2006-05-18 21:47:13
|
read-only cache for immutable collection causes unnecessary warning
-------------------------------------------------------------------
Key: HHH-1767
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1767
Project: Hibernate3
Type: Patch
Components: core
Versions: 3.1.3
Reporter: Alex Burgel
Priority: Trivial
Attachments: SessionFactoryImpl.patch
SessionFactoryImpl always says collections are mutable when calling the CacheFactory, even if the mapping file says otherwise. this causes a warning in the CacheFactory
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Alexandrino L. (JIRA) <no...@at...> - 2006-05-18 20:38:15
|
ExplodedJarVisitor and paths with white spaces
----------------------------------------------
Key: EJB-181
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-181
Project: Hibernate Entity Manager
Type: Bug
Components: EntityManager
Versions: 3.2.0.cr1
Environment: Sun's JRE 1.5.0_06; Tomcat 5.5.17; Windows XP Professional.
Reporter: Alexandrino Lucas
org.hibernate.ejb.packaging.ExplodedJarVisitor.doProcessElements() has the same problem and solution as issue EJB-178.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Gudlaugur E. (JIRA) <no...@at...> - 2006-05-18 17:09:24
|
Add support for explicit primary key names in table creation. Storage meta-attributes for DDL generation.
---------------------------------------------------------------------------------------------------------
Key: HHH-1766
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1766
Project: Hibernate3
Type: Patch
Components: metamodel
Versions: 3.2.0.cr2
Reporter: Gudlaugur Egilsson
Attachments: metamodel.patch
Add support for explicit primary key names in hbm files. Moves primary key definition into create-table statement from alter-table (easy to change back if you don't like that...). Primary key names are generated using old method if primary keys not provided.
Add support for storage meta-attributes for database (tablespace, initial extents). Useful for specifying tablespace and other storage attributes.
Patch created from rev#9933
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Aseel A. (JIRA) <no...@at...> - 2006-05-18 14:31:21
|
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-344?page=comments#action_23128 ] Aseel Abbas commented on ANN-344: --------------------------------- I just tried @Pattern and it showed the same problem. By 'overlapping' do you mean overlapping annotation elements? For example: class A { @Length (min = 0, max = 32) Integer getFoo() { return foo; } } class B extends A { @Length (max = 20) Integer getFoo() { return super.getFoo(); } } then validating an instance of class B which has a foo value of 100 will result in: "foo must be between 0 and 20" I think this would be nice to have but not as important as allowing the whole annotation to be over-ridden. we need to apply a particular type of validator, e.g. @Length, once and only once to a given property. BTW the order by which the method org.hibernate.validator.ClassValidator<T>.addSuperClassesAndInterfaces<T>(XClass clazz, Collection<XClass> classes) adds superclasses and interfaces may be good enough to determine the precedence of validators. I wish JSR 175 had proper inheritance support... > Base class validations are not over-ridden > ------------------------------------------ > > Key: ANN-344 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-344 > Project: Hibernate Annotations > Type: Improvement > Components: validator > Versions: 3.2.0.cr1 > Environment: hibernate 3.2 cr2 > Reporter: Aseel Abbas > > > When the same validation annotation is applied to an over-riding method in a subclass the expected behaviour is that the validation annotation in the base class is over-ridden. Currently, both validations are executed. This severely limits the usability of the package for domain models where inheritance is used. > The problem also occurs with over-riding interfaces. > For example: > class A { > @Length (min = 0, max = 32) > Integer getFoo() { > return foo; > } > } > class B extends A > { > @Length (min = 15, max = 20) > Integer getFoo() { > return super.getFoo(); > } > } > In this case validating an instance of class B which has a foo value of 100 will result in two error messages: "foo must be between 15 and 20" and "foo must be between 0 and 32". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-05-18 13:23:24
|
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-344?page=comments#action_23127 ] Emmanuel Bernard commented on ANN-344: -------------------------------------- Hum I don't know about that. It actually does not work for @Pattern, so I expect some other validations to need the overlaping between a method and it's overriden ones. > Base class validations are not over-ridden > ------------------------------------------ > > Key: ANN-344 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-344 > Project: Hibernate Annotations > Type: Improvement > Components: validator > Versions: 3.2.0.cr1 > Environment: hibernate 3.2 cr2 > Reporter: Aseel Abbas > > > When the same validation annotation is applied to an over-riding method in a subclass the expected behaviour is that the validation annotation in the base class is over-ridden. Currently, both validations are executed. This severely limits the usability of the package for domain models where inheritance is used. > The problem also occurs with over-riding interfaces. > For example: > class A { > @Length (min = 0, max = 32) > Integer getFoo() { > return foo; > } > } > class B extends A > { > @Length (min = 15, max = 20) > Integer getFoo() { > return super.getFoo(); > } > } > In this case validating an instance of class B which has a foo value of 100 will result in two error messages: "foo must be between 15 and 20" and "foo must be between 0 and 32". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Hendrik D (JIRA) <no...@at...> - 2006-05-18 13:21:21
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HB-417?page=comments#action_23126 ] Hendrik D commented on HB-417: ------------------------------ Since I'm not authorized to see the TODO list, can anyone tell me if there's some update for this issue? When is it due to be fixed? I don't actually see this as a 'new feature'. I didn't read any documentation stating that the criteria.createCriteria didn't work for many to one relations. Also, the behaviour is strange: it generates no join statement, but then tries to use the joined table in the where, resulting in invalid SQL. It took me a lot of time to find out what the problem was... > support createCriteria() for <key-many-to-one> > ---------------------------------------------- > > Key: HB-417 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HB-417 > Project: Hibernate2 > Type: New Feature > Components: core > Versions: 2.1 beta 4 > Environment: Win2k > SQLServer with jTds driver > Reporter: Sebastien Cesbron > Priority: Minor > Attachments: testHibernate.zip > > > I have one class Bar with a primary key composed of a 'key-many-to-one' to a class Foo. > I want to find a Bar instance with a Foo id so I have this criteria : > Criteria criteria = session.createCriteria(Bar.class); > criteria.createCriteria("foo").add(Expression.eq("id", new Integer(1))); > Bar bar = (Bar) criteria.uniqueResult(); > Then I have this sql statement > select this.ID_FOO as ID_FOO0_, this.text as text0_ from BAR this where x0_.id=1 > which fails because x0_ isn't defined. > With an HQL query it works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-05-18 13:16:19
|
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-344?page=all ] Emmanuel Bernard updated ANN-344: --------------------------------- Component: validator type: Improvement (was: Bug) Version: 3.2.0.cr1 Priority: Major > Base class validations are not over-ridden > ------------------------------------------ > > Key: ANN-344 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-344 > Project: Hibernate Annotations > Type: Improvement > Components: validator > Versions: 3.2.0.cr1 > Environment: hibernate 3.2 cr2 > Reporter: Aseel Abbas > > > When the same validation annotation is applied to an over-riding method in a subclass the expected behaviour is that the validation annotation in the base class is over-ridden. Currently, both validations are executed. This severely limits the usability of the package for domain models where inheritance is used. > The problem also occurs with over-riding interfaces. > For example: > class A { > @Length (min = 0, max = 32) > Integer getFoo() { > return foo; > } > } > class B extends A > { > @Length (min = 15, max = 20) > Integer getFoo() { > return super.getFoo(); > } > } > In this case validating an instance of class B which has a foo value of 100 will result in two error messages: "foo must be between 15 and 20" and "foo must be between 0 and 32". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Michael K. (JIRA) <no...@at...> - 2006-05-18 12:49:14
|
HQL Alias Regression
--------------------
Key: HHH-1765
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1765
Project: Hibernate3
Type: Bug
Components: query-hql
Versions: 3.1.3
Reporter: Michael Kopp
The following query worked fine in Hibernate 3.1.2
delete TokenConnection tc where exists
(
from Token as tok where rc.source = tok.id and tok.workflowInstance = ?
)
In Hibernate 3.1.3 I get an error because the FROM_TOKEN_ID column is invalid. That column is mapped to tc.source. I found out that the resulting SQL is:
delete from FT_WF_TKTN where exists
(select token1_.TOKEN_ID from FT_WF_TOKN token1_ where tokenconne0_.FROM_TOKEN_ID=token1_.TOKEN_ID and token1_.INSTANCE_ID=?)
Which can of course not work because the tokenconne0_ alias is not defined. it should be
delete from FT_WF_TKTN tokenconne0_ where exists
(select token1_.TOKEN_ID from FT_WF_TOKN token1_ where tokenconne0_.FROM_TOKEN_ID=token1_.TOKEN_ID and token1_.INSTANCE_ID=?)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: bible b. (JIRA) <no...@at...> - 2006-05-18 12:09:18
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-957?page=comments#action_23125 ] bible be commented on HHH-957: ------------------------------- I was having the same issue with hibernate 3.1.3. The proposed fix works perfectly, and I'm building some pretty complex queries. Please include this in the release asap! Thanks! > SubqueryExpression throws ClassCastException on DetachedCriteria subqueries > --------------------------------------------------------------------------- > > Key: HHH-957 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-957 > Project: Hibernate3 > Type: Bug > Versions: 3.0.5 > Environment: Oracle 9i, but probably not DB specific. > Reporter: Rob MacGrogan > Priority: Minor > Attachments: SubqueryExpression.java, SubqueryExpression.java > > > The toSqlString() method in SubqueryExpression contains a line that casts a Criteria object to CriteriaImpl in order to call the getSession() method. However, if DetachedCriteria is used as a subquery in a Criteria query, the underlying Criteria object will be CriteriaImpl.Subcriteria, thus a ClassCastException will be thrown. > I have created a bug fix. Add the following method to SubqueryExpression: > private SessionImpl getSessionImpl(Criteria criteria) { > SessionImpl session = null; > if (criteria instanceof CriteriaImpl) { > CriteriaImpl impl = (CriteriaImpl)criteria; > session = impl.getSession(); > } > else if (criteria instanceof CriteriaImpl.Subcriteria){ > CriteriaImpl.Subcriteria sub = (CriteriaImpl.Subcriteria)criteria; > //Alert! Recursive call here! > session = getSessionImpl(sub.getParent()); > } > return session; > } > And then replace the offending line in toSqlString() with a call to the new method. > Attached is SubqueryExpression with proposed changes in place. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Aseel A. (JIRA) <no...@at...> - 2006-05-18 10:27:31
|
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-344?page=comments#action_23124 ] Aseel Abbas commented on ANN-344: --------------------------------- The affected version is 3.2.0 cr2 and the module is validation. Jira crashed few times whilst I was submitting this and few fields where lost... > Base class validations are not over-ridden > ------------------------------------------ > > Key: ANN-344 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-344 > Project: Hibernate Annotations > Type: Bug > Environment: hibernate 3.2 cr2 > Reporter: Aseel Abbas > > > When the same validation annotation is applied to an over-riding method in a subclass the expected behaviour is that the validation annotation in the base class is over-ridden. Currently, both validations are executed. This severely limits the usability of the package for domain models where inheritance is used. > The problem also occurs with over-riding interfaces. > For example: > class A { > @Length (min = 0, max = 32) > Integer getFoo() { > return foo; > } > } > class B extends A > { > @Length (min = 15, max = 20) > Integer getFoo() { > return super.getFoo(); > } > } > In this case validating an instance of class B which has a foo value of 100 will result in two error messages: "foo must be between 15 and 20" and "foo must be between 0 and 32". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Aseel A. (JIRA) <no...@at...> - 2006-05-18 10:20:16
|
Base class validations are not over-ridden
------------------------------------------
Key: ANN-344
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-344
Project: Hibernate Annotations
Type: Bug
Environment: hibernate 3.2 cr2
Reporter: Aseel Abbas
When the same validation annotation is applied to an over-riding method in a subclass the expected behaviour is that the validation annotation in the base class is over-ridden. Currently, both validations are executed. This severely limits the usability of the package for domain models where inheritance is used.
The problem also occurs with over-riding interfaces.
For example:
class A {
@Length (min = 0, max = 32)
Integer getFoo() {
return foo;
}
}
class B extends A
{
@Length (min = 15, max = 20)
Integer getFoo() {
return super.getFoo();
}
}
In this case validating an instance of class B which has a foo value of 100 will result in two error messages: "foo must be between 15 and 20" and "foo must be between 0 and 32".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Jaka J. (JIRA) <no...@at...> - 2006-05-18 02:51:17
|
Cache invalidation in OptimisticTreeCache conflicts with JTA transactions
-------------------------------------------------------------------------
Key: HHH-1764
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1764
Project: Hibernate3
Type: Patch
Components: core
Versions: 3.2.0.cr2
Environment: Hibernate 3.1.3 with added OptimisticTreeCache classes from 3.2.0.cr2, JBoss Cache 1.3 SP2, JBoss 4.0.3 SP1, PostgreSQL 8.1.2
Reporter: Jaka Jaksic
Attachments: OptimisticTreeCache.patch
After switching to Hibernate 3.2.0.cr2's OptimisticTreeCache, exceptions started to occur after every commit. The reason is that, unlike TreeCache, OptimisticTreeCache doesn't perform cache invalidation _outside_ the scope of JTA transaction, even though the comment in its put() method states so... So because cache invalidation happens after commit, when the tx status is set to 3 (STATUS_COMMITTED), which TreeCache finds invalid, the following exception occurs:
00:53:51,754 WARN [TreeCache] status is 3 (not ACTIVE or PREPARING); returning null)
00:53:51,754 INFO [TxInterceptor] There was a problem handling this request org.jboss.cache.CacheException: Must be in a valid transaction _put(null, /org/hibernate/cache/UpdateTimestampsCache/EVENT_LOG, item, 11479064317, true)
The original TreeCache properly bypasses JTA transaction by calling suspend(). I don't know why OptimisticTreeCache doesn't do that as well. I just copied that code from the TreeCache class and it seems to work well.
If there is a reason why OptimisticTreeCache should not do it this way, please let me know what it is and how to solve this problem properly. Otherwise just use the provided patch.
Here's the full stack trace:
00:53:51,754 WARN [TreeCache] status is 3 (not ACTIVE or PREPARING); returning null)
00:53:51,754 INFO [TxInterceptor] There was a problem handling this request org.jboss.cache.CacheException: Must be in a valid transaction _put(null, /org/hibernate/cache/UpdateTimestampsCache/EVENT_LOG, item, 11479064317, true)
at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:113)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:68)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:76)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:116)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:328)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:139)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:153)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:4804)
at org.jboss.cache.TreeCache.put(TreeCache.java:3242)
at org.jboss.cache.TreeCache.put(TreeCache.java:2937)
at org.hibernate.cache.OptimisticTreeCache.put(OptimisticTreeCache.java:139)
at org.hibernate.cache.UpdateTimestampsCache.invalidate(UpdateTimestampsCache.java:67)
at org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:174)
at org.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:419)
at org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(JDBCContext.java:209)
at org.hibernate.transaction.CacheSynchronization.afterCompletion(CacheSynchronization.java:85)
at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1508)
at org.jboss.tm.TransactionImpl.completeTransaction(TransactionImpl.java:1180)
at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:359)
at org.jboss.tm.TxManager.commit(TxManager.java:224)
at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:126)
at org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:146)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: <no...@at...> - 2006-05-17 22:25:14
|
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-98?pag= e=3Dall ] Micha=C5=82 Borowiecki updated EJB-98: --------------------------------- Attachment: DefaultLoadEventListener.patch The DefaultLoadEventListener.loadFromSessionCache method throws ObjectDelet= edException if the option checkDeleted =3D=3D true and the entity is DELETE= D or GONE. One way to fix this bug is to make it return null instead of throwing the e= xception. I have examined the usages of this class and I think returning null here is= the reasonable thing to do. It will still be consistent with the API doc for this method, which merely = states that its status is checked: "If checkDeleted was set to true, then if the entity is found in the sessio= n-level cache, it's current status within the session cache is checked to s= ee if it has previously been scheduled for deletion." The method createProxyIfNecessary should behave the same way.=20 I attach a patch modifying both methods to return null in this case instead= of throwing the exception. > EntityManager.find() throws an org.hibernate.ObjectDeletedException if yo= u find something deleted in the same TXA > -------------------------------------------------------------------------= ---------------------------------------- > > Key: EJB-98 > URL: http://opensource.atlassian.com/projects/hibernate/browse/E= JB-98 > Project: Hibernate Entity Manager > Type: Bug > Components: EntityManager > Versions: 3.1beta5 > Environment: Java 1.5.06/junit3.8.1,hibernate 3.1, entity manager 3.1bet= a5, hsqldb 1.8.01 > Reporter: Steve Loughran > Fix For: 3.2.0 > Attachments: DefaultLoadEventListener.patch > > > I have a junit test case that persists something, finds it, then deletes = it and tries to find again. > Second time round, find() fails with an ObjectDeletedException. This is t= he semantics of Session.load(), not EntityManager.find(), which is meant to= return null if something cannot be found: > public void testDeleteAndFindFailsWrong() throws Exception { > Event event =3D createTestEvent(); > String key =3D event.getKey(); > EntityTransaction transaction =3D null; > try { > transaction =3D manager.getTransaction(); > transaction.begin(); > manager.persist(event); > Event e2 =3D manager.find(Event.class, key); > assertEquals(event, e2); > manager.remove(e2); > try { > e2 =3D manager.find(Event.class, key); > assertNull("The spec says that find should return null he= re", e2); > } catch (ObjectDeletedException e) { > fail("This is not in the spec"+e); > } > } finally { > rollback(transaction); > } > } =20 --=20 This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators= .jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
93 messages has been excluded from this view by a project administrator.
