April 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-517) ThreadLocal in ContextHolder causes memory leak when deployed in a web container

by Vojtěch Krása (JIRA)

ThreadLocal in ContextHolder causes memory leak when deployed in a web container -------------------------------------------------------------------------------- Key: HSEARCH-517 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-517 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.2.0.CR1, 3.2.0.Beta1, 3.1.1.GA, 3.1.0.GA, 3.1.0.CR1, 3.1.0.Beta2, 3.1.0.Beta1, 3.0.1.GA, 3.0.0.GA Environment: Hibernate 3.4.0.GA/3.5.1-Final, Tomcat 6.0.26, Spring 2.5.6/3.0.1, Sun JDK 1.6; Hibernate 3.3.1.GA Tomcat 6.0.18 Spring 2.5.6 Java OpenJDK 1.6 Reporter: Vojtěch Krása Priority: Critical Attachments: dump.zip, testCase.zip The SearchFactory has a static ThreadLocal variables which holds a reference to the SearchFactoryImpl. The ThreadLocal is not cleared when the application is undeployed, causing a memory leak. http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-314 -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3527) Null Version Comparator for versioned class due to reuse of Second Level CacheDataDescriptionImpl

by Paul FitzPatrick (JIRA)

Null Version Comparator for versioned class due to reuse of Second Level CacheDataDescriptionImpl ------------------------------------------------------------------------------------------------- Key: HHH-3527 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3527 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.3.1 Environment: 3.3.1 GA, Postgres 8.3.3, EH Cache Reporter: Paul FitzPatrick Priority: Minor When the SessionFactoryImpl constructor builds the EntityPersister for classes, it consults a cache of entityAccessStrategies for all the known second level cache regions. If only some of the classes in that region have version tags, then it is possible the cached EntityRegionAccessStrategy will be created without a Version Comparator. Subsequent calls to load an object using a Criteria query failed with a NullPointerException (stack trace below). The line being executed is "return version!=null && comparator.compare(version, newVersion) < 0;" and in this case "version" is an Integer object and comparator is null. Not sure the appropriate solution. It would seem from an examination of the code that if the EntityRegionAccessStrategy is to be shared, then all classes in the second level cache region _must_ either all have a "version" column or all have no "version" column. Further, it seems implied that if they use a "version" column, then they must all use the exact same data type. If this is the case, then a better error check on the configuration data may be in order. Caused by: java.lang.NullPointerException at org.hibernate.cache.ReadWriteCache$Item.isPuttable(ReadWriteCache.java:426) at org.hibernate.cache.ReadWriteCache.put(ReadWriteCache.java:180) at org.hibernate.cache.impl.bridge.EntityAccessStrategyAdapter.putFromLoad(EntityAccessStrategyAdapter.java:68) at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:179) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:877) at org.hibernate.loader.Loader.doQuery(Loader.java:752) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259) at org.hibernate.loader.Loader.doList(Loader.java:2228) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125) at org.hibernate.loader.Loader.list(Loader.java:2120) at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1596) at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306) at org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:328) -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-433) Think about exposing not yet committed changes by opening IndexReaders off IndexWriters

by Emmanuel Bernard (JIRA)

Think about exposing not yet committed changes by opening IndexReaders off IndexWriters --------------------------------------------------------------------------------------- Key: HSEARCH-433 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-433 Project: Hibernate Search Issue Type: Sub-task 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-511) Clean up orphaned lock files on startup

by Marc Schipperheyn (JIRA)

Clean up orphaned lock files on startup --------------------------------------- Key: HSEARCH-511 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-511 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 3.2.0.CR1 Reporter: Marc Schipperheyn I have had several occassions when the MassIndexer failed to complete for some reason and I had to restart Tomcat. MassIndexer creates lockfiles for the indexes it is updating. These lock files remain after a restart and block MassIndexer from running again. I suggest that Hibernate Search during startup checks for the existence of lock files in the index directory and removes then if they are there. This prevents an administrator from having to go and do it manually which is a bummer in production. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3936) Provide Hibernate Dialect for MS SQL Server 2005

by Claudio (JIRA)

Provide Hibernate Dialect for MS SQL Server 2005 ------------------------------------------------ Key: HHH-3936 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3936 Project: Hibernate Core Issue Type: Task Environment: Hibernate 3.3.1 Reporter: Claudio Attachments: SQLServer2005Dialect.java Hibernate should support a dialect for MS SQL Server 2005. There are some particularities comparing to SQL Server 2000 (SQL Limit strategy for example). Find the dialect attached. Test Case must be created for it. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HV-230) Database Connective or @Unique

by Ken Egervari (JIRA)

Database Connective or @Unique ------------------------------ Key: HV-230 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-230 Project: Hibernate Validator Issue Type: New Feature Affects Versions: 3.1.0.GA Reporter: Ken Egervari Priority: Critical I find a common validation use case is checking to see if a field is unique to all those in the table, such as emails, isbns, usernames, keywords, etc. these fields may not be the primary key, but still need to be unique. It would be fantastic if hibernate validator implemented this. This is a common problem though because the domain class will need to have access the database. I dunno if there's an easy way to wire in a copy of sessionFactory to make this easy to write. Perhaps something like this: @Query( "select user from User user where user.emailAddress = :this.emailAddress and user.id != :this.id", message = "That Email is already being used by another user in the system" ) private String emailAddress; Basically the idea is that if @Query returns no results, then the validation constraint is good, and if returns more than 1 result, then it fails. Kind of like simpleJdbcTemplate.queryForMap() does within the Spring testing framework. That method causes the test to fail if no row is returned, because it expects 1 result. If it were possible to just say @Unique private String emailAddress; That would be extremely concise and would save people a ton of time. Of course, this requires some interoperability with Hibernate... but I think that's a good thing, no? Thanks for taking this into consideration. I'd appreciate an email letting me know how to do this in a clean way in 3.1.0 GA as it is as well if you would. Thank you. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
9
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-307) Implement clustering with JBoss Cache

by Hardy Ferentschik (JIRA)

Implement clustering with JBoss Cache ------------------------------------- Key: HSEARCH-307 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-307 Project: Hibernate Search Issue Type: New Feature Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2716) Session.replicate failure with identity column

by Yves Martin (JIRA)

Session.replicate failure with identity column ---------------------------------------------- Key: HHH-2716 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2716 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.2 Environment: Java 1.5, MySQL 5.0.27 and Hibernate Annotations 3.2.1.GA Reporter: Yves Martin I'm trying to use replicate: http://www.hibernate.org/hib_docs/reference/en/html/objectstate.html#obje... The column "@version" is replicated properly (same value in second db) but the column "@Id @GeneratedValue" contains a new value from the db2 sequence. In fact the insert statement generated by the replicate method does not include the "id" column. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

6
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4795) Comparing OneToOne mappedBy column to null generates wrong SQL

by Uros Majeric (JIRA)

Comparing OneToOne mappedBy column to null generates wrong SQL -------------------------------------------------------------- Key: HHH-4795 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4795 Project: Hibernate Core Issue Type: Bug Environment: Hibernate core 3.3.2.GA Postgresql 8.4 Reporter: Uros Majeric I have two entities: @Entity @Table(name = "beer_keg") public class Keg implements Serializable { @Id @GeneratedValue @Column(name = "bkid") public Long getId() { return id; } public void setId(Long id) { this.id = id; } @OneToOne(mappedBy="keg", fetch=FetchType.LAZY, optional=true) public KegValveCombination getCombination() { return combination; } void setCombination(KegValveCombination combination) { this.combination = combination; } } and @Entity @Table(name="keg_valve_combination") public class KegValveCombination implements Serializable { @Id @GeneratedValue @Column(name="id", nullable=false) public Long getId() { return id; } public void setId(Long id) { this.id = id; } @OneToOne(cascade=CascadeType.ALL) @JoinColumn(name="keg", nullable=false, unique=true) public Keg getKeg() { return keg; } public void setKeg(Keg keg) { this.keg = keg; } } if I create query: em.createQuery("FROM Keg k WHERE k.combination is null").getResultList(); hibernate generates sql like: select keg0_.* from beer_keg keg0_ where keg0_.bkid is null but it should be: select keg0_.* from beer_keg keg0_ left join keg_valve_combination kegvalveco1_ on keg0_.bkid=kegvalveco1_.keg where (kegvalveco1_.keg is null) thanks, Uros -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4453) Reserved keywords not quoted in table/column names

by Philipp Reichart (JIRA)

Reserved keywords not quoted in table/column names -------------------------------------------------- Key: HHH-4453 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4453 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: Hibernate 3.3.1 GA, Windows XP, Sun JDK 1.6.0_06, Derby 10.5 Reporter: Philipp Reichart I'm currently migrating our test suite form HSQLDB to Derby (we need transaction isolation and the HSLDB 1.9 RCs are no good), and found out that we have a lot of table or colum names that happen to be reserved keywords in Derby, like "transaction", "key", "value", "year", etc.. The usual workaround seems to be adding backticks to any offending table/column name in our hbm.xml files, but that's really an ugly workaround and doesn't prevent later incidents of this kind when new keywords show up in either our mappings or database. As this is about a production database schema, reanming the table/column names isn't an option either. I already tried implementing a custom Derby dialect and registering all the keywords from the Derby doc at http://db.apache.org/derby/docs/10.5/ref/rrefkeywords29722.html and even defined a "quote everything" NamingStrategy using the dialect to get the correct native quotes for the database. Unfortunately, neither the Hibernate DDL generator nor HQL queries seem to consider the naming strategy or dialect when handling table or column names. Is there any way to have Hibernate quote database-specific keywords every they're used? Or just have Hibernate quote everything that comes from a mapping file? -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2010