May 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2907) ability to apply 'generation strategy' to generated properties

by Steve Ebersole (JIRA)

ability to apply 'generation strategy' to generated properties -------------------------------------------------------------- Key: HHH-2907 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2907 Project: Hibernate3 Issue Type: New Feature Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Priority: Minor Fix For: 3.3 Currently, the support for generated properties allows only for db-generated values (ala triggers etc). Would be great to allow the user to provide a seperate (optional) strategy for generating the generated values. It would be nice to have a generic solution, which we can build on top of for the more common use cases. Also, we may need to use a name other than 'generated' in the annotations to avoid conflicts with the current @Generated annotation; for now lets use the term @Dynamic. Consider mapping a 'created timestamp' column. Currently, provided we are using a trigger, that would look like: @Generated(INSERT) Date created; The strategy here (^^) is implicitly 'db', as the db is taking care of the generation. In the most generic form, that could be written as: @Dynamic(time=INSERT,strategy=DB) Date created; Additionally, since this is such a common case, also allow this: @CreationTimestamp Date created; The final form would also allow the definition of strategies. As an example, consider: @CreationTimestamp(strategy=NOW) Date created; Here we are not relying on the db to generate the value, but are explicitly telling Hibernate to do it (basically 'use the current timestamp to generate a value here whenever we do an insert'). -- 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

14 years, 4 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4521) Hibernate/Infinispan integration doesn't property handle Entity/CollectionRegionAccessStrategy evict(Object)

by Galder Zamarreno (JIRA)

Hibernate/Infinispan integration doesn't property handle Entity/CollectionRegionAccessStrategy evict(Object) ------------------------------------------------------------------------------------------------------------ Key: HHH-4521 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4521 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.5 Port HHH-4517 to Infinispan second level cache integration. -- 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

14 years, 4 months

3
12
0 / 0

[Hibernate-JIRA] Created: (HHH-4048) Phase 2 - implement rest of strategies

by Steve Ebersole (JIRA)

Phase 2 - implement rest of strategies -------------------------------------- Key: HHH-4048 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4048 Project: Hibernate Core Issue Type: Sub-task Reporter: Steve Ebersole Assignee: Steve Ebersole -- 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

14 years, 4 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3800) Allow chopping of class names in various logging scenarios

by Steve Ebersole (JIRA)

Allow chopping of class names in various logging scenarios ---------------------------------------------------------- Key: HHH-3800 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3800 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Priority: Minor When logging enti ty class names, it would be nice to allow "collapsing" or "stripping" the entity name in various ways. Or when referencing Hibernate classes... -- 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

14 years, 4 months

1
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5223) Allow 2-phase load of components

by Steve Ebersole (JIRA)

Allow 2-phase load of components -------------------------------- Key: HHH-5223 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5223 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6 -- 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

14 years, 4 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5037) Improve documentation for immutable/read-only entity and immutable collection functionality

by Gail Badner (JIRA)

Improve documentation for immutable/read-only entity and immutable collection functionality ------------------------------------------------------------------------------------------- Key: HHH-5037 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5037 Project: Hibernate Core Issue Type: Improvement Components: documentation Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.5.0.Next -- 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

14 years, 4 months

3
14
0 / 0

[Hibernate-JIRA] Created: (HHH-4814) Improve IsolatedClassloaderTest so that primary key is also custom

by Galder Zamarreno (JIRA)

Improve IsolatedClassloaderTest so that primary key is also custom ------------------------------------------------------------------ Key: HHH-4814 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4814 Project: Hibernate Core Issue Type: Task Components: caching (L2) Affects Versions: 3.5.0-Beta-3 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.5.0-Beta-4 Improve IsolatedClassloaderTest and corresponding entities so that not only a custom type if used in the query as parameter, but the entity's primary key is also a custom type. http://lists.jboss.org/pipermail/jboss-development/2010-January/015466.html -- 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

14 years, 4 months

3
9
0 / 0

[Hibernate-JIRA] Created: (HHH-4759) Create unit test for flush/rollback issue when JDBCTransactionFactory in use with Infinispan

by Galder Zamarreno (JIRA)

Create unit test for flush/rollback issue when JDBCTransactionFactory in use with Infinispan -------------------------------------------------------------------------------------------- Key: HHH-4759 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4759 Project: Hibernate Core Issue Type: Task Components: caching (L2) Affects Versions: 3.5.0-Beta-2 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Priority: Minor Fix For: 3.5 Create a UT that replicates what's being reported here when JDBC transaction factory is in use: http://community.jboss.org/message/517376#517376 -- 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

14 years, 4 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5234) 2-phase load components

by Steve Ebersole (JIRA)

2-phase load components ----------------------- Key: HHH-5234 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5234 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6 This piece is the crux needed for many of the planned improvements wrt components: # component inheritance (discriminator based) # full key-many-to-one support # 'loaded state' tracking for orphan delete semantics -- 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

14 years, 4 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2079) Add pre flush event listener holding all the changed entities and the operations on them

by Shay Banon (JIRA)

Add pre flush event listener holding all the changed entities and the operations on them ---------------------------------------------------------------------------------------- Key: HHH-2079 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2079 Project: Hibernate3 Type: New Feature Components: core Versions: 3.2.0.ga Reporter: Shay Banon Is there a chance to add a pre flush event listener. The event listener will have all the entities changes about to be flushed, including the operation about to be performed on them (delete, update, create). This issue relates to HHH-1725 and the collection not processed by flush exception. Maybe there would be a chance to load the lazy collections before the actual flush operation using the mentioned listener. -- 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

14 years, 4 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2434) No standard way to calculate date intervals in HQL

by Don Smith (JIRA)

No standard way to calculate date intervals in HQL -------------------------------------------------- Key: HHH-2434 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2434 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.ga Environment: All Reporter: Don Smith Priority: Minor Date interval calculation is supported differently on different database platforms. Some allow direct arithmetic on columns, i.e. enddate - startdate. Some require functions, datediff(), timestampdiff(), etc. This causes cross-platform issues. For instance, an application I work on has to figure out the dialect that's in use (out of the four we currently support) and create the HQL string differently for each platform. This is undesirable, since we use Hibernate to enable platform neutrality; our installer asks which database the customer wants to deploy to, and sets the dialect. We'd like our codebase to be free of dialect-specific code. I propose a standard solution for this, either direct date arithmetic, or a function defintion that is ported across dialects. Timestampdiff seems to be a fairly standard function, although DB2 has different syntax than MySQL and Derby. I've seen hints that timestampdiff is part of the ANSI SQL standard, but do not have access to the documents to determine if that is the case. -- 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

14 years, 4 months

6
16
0 / 0

[Hibernate-JIRA] Created: (HHH-3348) loading context

by benjamin Leroux (JIRA)

loading context --------------- Key: HHH-3348 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3348 Project: Hibernate3 Issue Type: New Feature Affects Versions: 4.x Reporter: benjamin Leroux Priority: Minor this proposal is for creating a loading context into hibernate Let me explain: On an application, we often hesitating between the two major strategies of loading (eager or lazy). But for some reason there has no good choice. In fact, it depends on the context. So we do lazy loading and redefine some method with new request with some "join". In fact, it lead to complexity and decrease managability of the application. So my idea is to allow the definition of a context (like transactional context) where we we can put the loading strategie to adopt. with annotation it could be very easy to define such context. Let see this exemple : Avec les annotations, cela pourrait conduire à une ecriture de ce style : @LoadingStrategie (type=eager from="Car" get={"driver"}) public List<Car> getAllCarForDriving(){ // Some fonctions } @LoadingStrategie (type=eager from="Car" get={"driver","passengers"}) public List<Car> getAllCarForTravelling(){ // Some fonctions } In the method getAllCarForDriving when we call a hql request on car it automaticaly get driver but in the method getAllCarForTravelling passengers and the driver is loaded. -- 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

14 years, 4 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5184) Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode

by Steve Ebersole (JIRA)

Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode ------------------------------------------------------------------------ Key: HHH-5184 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5184 Project: Hibernate Core Issue Type: Improvement Reporter: Steve Ebersole Fix For: 3.6 Originally ConnectionReleaseMode was added to work around a particular problem of connection "leaking" by JTA containers when used in situations of nested session EJB calls. The connection was not really leaked, but it would appear that way to the JTA resource tracker. The situation was: {code} class EJB1 { public void doSomething() { Session s = getCurrentSession(); ... ejb2.doSomethingElse(); // now use the HIbernate session } } class EJB2 { public void doSomethingElse() { Session s = getCurrentSession(); // Use the session in a way that requires a Connection... } } {code} What happens is that EJB1 obtains a Session reference. Just getting a Hibernate Session does not make it get a Connection; the Session delays getting a Connection until it actually needs one. EJB1 then makes the call into EJB2. Again, EJB2 obtains the same Session reference and does some work, so the Session obtains a Connection. Historically that Connection would be held until the Session closed. However that was problematic in this scenario above; to the JTA container it looks like EJB2.doSomethingElse() is leaking the connection outside the transaction boundary (this was many years ago and AFAIU many of these JTA scoping routines have become more sophisticated). At the time we decided to add the idea of Connection "releasing". However constantly releasing and re-obtaining the Connection can affect performance. Another solution to the problem above is to obtain the Connection up front instead. So initially I see: ConnectionAcquisitionMode.AS_NEEDED ConnectionAcquisitionMode.IMMEDIATELY -- 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

14 years, 4 months

1
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3512) Registration of IdentifierGenerators (short naming)

by Steve Ebersole (JIRA)

Registration of IdentifierGenerators (short naming) --------------------------------------------------- Key: HHH-3512 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3512 Project: Hibernate Core Issue Type: New Feature Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.4, 4.x Another way to look at this is to allow configuration of IdentifierGeneratorFactory. Either allow explicit registration under a short name in config: <identifier-generator name="sequence-style" class="org.hibernate.id.enhanced.SequenceStyleGenerator"/> or via an explicit contract: public interface Registerable { public String getRegistrationName(); } public class SequenceStyleGenerator implements IdentifierGenerator, Registerable { ... public String getRegistrationName() { return "sequence-style"; } } The second, while certainly more verbose, can be used applied to other situations where we want to allow registration moving forward (types, property-accessor, etc). -- 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

14 years, 4 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2764) EntityType.deepCopy needs to copy for EntityType.DOM4J

by Alan Krueger (JIRA)

EntityType.deepCopy needs to copy for EntityType.DOM4J ------------------------------------------------------ Key: HHH-2764 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2764 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.2 Environment: Hibernate 3.2.2 Reporter: Alan Krueger Using DOM4J with a set of composite-elements that contains a many-to-one. When loading this from the database, the many-to-one piece of the composite-element is disappearing from the XML. I can see the collection being built and the properties on the elements of the collection being set, but the many-to-one property disappears after that. Investigating this, it looks like when PersistentElementHolder.getSnapshot is called and a deepCopy is performed, the EntityType.deepCopy method returns the value to be copied rather than copying it. This interacts poorly with the DOM4J tree, since each Element can only have a single Element parent. When the properties are set on this, a detach is performed that yanks the original element out of its parent. -- 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

14 years, 4 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-4739) InheritanceType.SINGLE_TABLE don't work with Postgresql 8.4.1 and postgresql-8.4-701.jdbc3.jar

by Robert Anderson Nogueira de Oliveira (JIRA)

InheritanceType.SINGLE_TABLE don't work with Postgresql 8.4.1 and postgresql-8.4-701.jdbc3.jar ---------------------------------------------------------------------------------------------- Key: HHH-4739 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4739 Project: Hibernate Core Issue Type: Bug Components: annotations, core, entity-manager, testsuite Affects Versions: 3.3.1 Environment: JBoss Seam 2.2.0-GA, PostgreSQL 8.4.1, postgresql-8.4-701.jdbc3.jar Reporter: Robert Anderson Nogueira de Oliveira Attachments: main-classes.zip @Entity public class FenomenoMetadado implements Serializable { /** * */ private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Integer id; @NotNull private String nome; private String descricao; @OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL, mappedBy = "fenomenoMetadado") private List<AtributoMetadado> atributosMetadado; /* Getters and Setters */ } @Entity @Inheritance(strategy=InheritanceType.SINGLE_TABLE) public abstract class AtributoMetadado implements Serializable { /** * */ private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy=GenerationType.IDENTITY) private Integer id; @NotNull private String nome; @NotNull private String label; @NotNull private Boolean requerido; @ManyToOne @JoinColumn(name="fenomenometadado_id", nullable = false) private FenomenoMetadado fenomenoMetadado; /* Getters and Setters */ } @Entity public class StringMetaDado extends AtributoMetadado { /** * */ private static final long serialVersionUID = 1L; } TestNG: public class FenomenoMetadadoTests extends SeamTest { @Test public void testarCriarRemover() throws Exception { final FenomenoMetadado instalacaoMetaDado = new FenomenoMetadado(); instalacaoMetaDado.setNome("Instalações"); instalacaoMetaDado.setDescricao("Instalações de Petróleo e Gás"); List<AtributoMetadado> atributos = new ArrayList<AtributoMetadado>(); StringMetaDado att1 = new StringMetaDado(); att1.setLabel("Nome"); att1.setNome("nome"); att1.setRequerido(true); att1.setFenomenoMetadado(instalacaoMetaDado); atributos.add(att1); instalacaoMetaDado.setAtributosMetadado(atributos); new FacesRequest() { protected void invokeApplication() { EntityManager em = (EntityManager) getValue("#{entityManager}"); try { em.persist(instalacaoMetaDado); } catch (Exception e) { e.printStackTrace(); fail("Hibernate Bug with postgresql-8.4-701.jdbc3.jar"); } } }.run(); } Stacktrace: Hibernate: insert into FenomenoMetadado (descricao, nome) values (?, ?) Hibernate: insert into AtributoMetadado (fenomenometadado_id, label, nome, requerido, DTYPE) values (?, ?, ?, ?, 'StringMetaDado') ERROR [org.hibernate.util.JDBCExceptionReporter] Valor inválido para tipo int : StringMetaDado javax.persistence.PersistenceException: org.hibernate.exception.DataException: could not insert: [org.domain.geoinfra.entity.StringMetaDado] at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614) at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:226) at org.jboss.seam.persistence.EntityManagerProxy.persist(EntityManagerProxy.java:137) at org.hibernate.search.jpa.impl.FullTextEntityManagerImpl.persist(FullTextEntityManagerImpl.java:93) at org.jboss.seam.persistence.EntityManagerProxy.persist(EntityManagerProxy.java:137) at tests.FenomenoMetadadoTests$2.invokeApplication(FenomenoMetadadoTests.java:74) at org.jboss.seam.mock.AbstractSeamTest$Request.invokeApplicationPhase(AbstractSeamTest.java:646) at org.jboss.seam.mock.AbstractSeamTest$Request.emulateJsfLifecycle(AbstractSeamTest.java:595) at org.jboss.seam.mock.AbstractSeamTest$Request.access$100(AbstractSeamTest.java:177) at org.jboss.seam.mock.AbstractSeamTest$Request$2.doFilter(AbstractSeamTest.java:497) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178) at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495) at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.jboss.seam.mock.AbstractSeamTest$Request.run(AbstractSeamTest.java:491) at tests.FenomenoMetadadoTests.testarCriarRemover(FenomenoMetadadoTests.java:82) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644) at org.testng.internal.Invoker.invokeMethod(Invoker.java:546) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:700) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1002) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:137) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:121) at org.testng.TestRunner.runWorkers(TestRunner.java:908) at org.testng.TestRunner.privateRun(TestRunner.java:617) at org.testng.TestRunner.run(TestRunner.java:498) at org.testng.SuiteRunner.runTest(SuiteRunner.java:329) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:324) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:296) at org.testng.SuiteRunner.run(SuiteRunner.java:201) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915) at org.testng.TestNG.runSuitesLocally(TestNG.java:879) at org.testng.TestNG.run(TestNG.java:787) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:75) at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:127) Caused by: org.hibernate.exception.DataException: could not insert: [org.domain.geoinfra.entity.StringMetaDado] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:100) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:64) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2186) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2666) at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:71) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:321) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:130) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49) at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628) at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192) at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319) at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192) at org.hibernate.engine.Cascade.cascade(Cascade.java:153) at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:479) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:357) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:130) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49) at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:645) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:619) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:623) at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:220) ... 50 more Caused by: org.postgresql.util.PSQLException: Valor inválido para tipo int : StringMetaDado at org.postgresql.jdbc2.AbstractJdbc2ResultSet.toInt(AbstractJdbc2ResultSet.java:2759) at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getInt(AbstractJdbc2ResultSet.java:2003) at org.jboss.resource.adapter.jdbc.WrappedResultSet.getInt(WrappedResultSet.java:673) at org.hibernate.id.IdentifierGeneratorFactory.get(IdentifierGeneratorFactory.java:107) at org.hibernate.id.IdentifierGeneratorFactory.getGeneratedIdentity(IdentifierGeneratorFactory.java:92) at org.hibernate.id.IdentityGenerator$GetGeneratedKeysDelegate.executeAndExtract(IdentityGenerator.java:98) at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:57) ... 83 more If I use the jdbc driver postgresql-8.3-605.jdbc3.jar it works fine. -- 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

14 years, 4 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-4450) MapKey with key as entity not working

by shay (JIRA)

MapKey with key as entity not working -------------------------------------- Key: HHH-4450 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4450 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: hibernate annotations 3.4.0 , Hibernate-core 3.3.2 , Postgres 1.8.4 Reporter: shay Priority: Blocker Attachments: testbug.zip when using an entity as key , map is inaccessible(NullPointerException for items) . Its seems that when HashCode is called on the Key , the properties in key have not been populated, which prevents the map from loading properly Test case attached Thank you for your help Shay Matasaro -- 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

14 years, 4 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5235) MultipleHiLoPerTableGenerator infers catalogs and schemas where none should be inferred

by Laird Nelson (JIRA)

MultipleHiLoPerTableGenerator infers catalogs and schemas where none should be inferred --------------------------------------------------------------------------------------- Key: HHH-5235 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5235 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2 Environment: Hibernate 3.5.2-Final, H2 database version 1.2.134 Reporter: Laird Nelson I have a @TableGenerator annotation and an associated @GeneratedValue like this: @Entity(name = "PostalAddress") @TableGenerator( name = "PostalAddressEntityIDGenerator", table = "JPAGenerators", pkColumnName = "generatorName", pkColumnValue = "PostalAddressEntityIDGenerator", valueColumnName = "generatorValue", allocationSize = 1 ) public class PostalAddressEntity { @GeneratedValue(strategy = GenerationType.TABLE, generator = "PostalAddressEntityIDGenerator") @Id private long id; /* etc. */ } At runtime, the following SQL shows up: select generatorValue from JPAGenerators.JPAGenerators.JPAGenerators where generatorName = 'PostalAddressEntityIDGenerator' for update Note the table name repeated three times as though it is both the catalog, the schema and the table name. It seems that the MultipleHiLoPerTableGenerator, when asked to build its SQL strings for various operations, is told that the schema, the catalog and the table name are all the same. I was expecting that the catalog would default to "", per the TableGenerator documentation, and that the schema would default to whatever was present in orm.xml's persistence-unit-defaults element. I can work around this by explicitly spelling out the schema name in my @TableGenerator annotation, but I don't want to put it there (can't, actually). I can also work around this in a JPA-compliant manner by defining my table generator in my orm.xml file, but I don't want to do that either. -- 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

14 years, 4 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-472) Runtime creation of new shards

by Dobes Vandermeer (JIRA)

Runtime creation of new shards ------------------------------ Key: HSEARCH-472 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-472 Project: Hibernate Search Issue Type: New Feature Components: query Affects Versions: 3.2.0.Beta1 Reporter: Dobes Vandermeer Priority: Minor Hibernate Search's shard support has added the ability to select a shard based on a parameter of the query; however, you must use a fixed number of shards. In order to best support our use case originally reported in http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-470 it would be necessary to add support for dynamically added shards at runtime. Also related: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-251 and http://www.opensubscriber.com/message/hibernate-dev@lists.jboss.org/97703... -- 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

14 years, 4 months

3
28
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-521) Improve performance MassIndexer through Eager fetching

by Marc Schipperheyn (JIRA)

Improve performance MassIndexer through Eager fetching ------------------------------------------------------ Key: HSEARCH-521 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-521 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 3.2.0.CR1 Reporter: Marc Schipperheyn Priority: Minor The MassIndexer fetches all of a certain entity from the database. It then proceeds to index it and the tree of IndexedEmbedded objects is traversed. In doing so, a lot of additional queries get executed. These queries are not really necessary, since we know beforehand that the data is needed for the indexing operation. So it would make sense to eagerly fetch all associations that are marked as indexEmbedded. This way MassIndexer would significantly speed up. -- 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

14 years, 4 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-349) Allow custom Loader in FullTextQueryImpl

by Julien Kronegg (JIRA)

Allow custom Loader in FullTextQueryImpl ---------------------------------------- Key: HSEARCH-349 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-349 Project: Hibernate Search Issue Type: New Feature Components: query Affects Versions: 3.1.0.GA Environment: Hibernate 3.3.1.GA, DB2 Reporter: Julien Kronegg Priority: Minor When doing an native SQL query containing join and other complicated stuff, one can get a List<MyObject> using the following code: List<MyObject> list = entityManager.createNativeQuery("SELECT ...", MyObject.class).getResultList(); The MyObject class is an JPA Entity, but is not connected to a database table: the MyObject instance is reconstructed automatically by mapping the ResultSet column names and the MyObject field names. This object list can be indexed using Hibernate Search (by adding @Indexed and @Field annotations to the MyObject entity). When doing an Hibernate Search query, the FullTextQueryImpl.list() method uses a Loader which try to load the MyObject entities from the database by a query such as "SELECT ... FROM MYOBJECT where id in (?,?,?,..)" (where the list of "?" is the list of identifiers returned by Lucene). Here, we have a problem: the MYOBJECT table does not exist and obviously an exception is raised. The desired result would be for example to look into the initial List<MyObject> "list" instead of asking to the database. This functionnality could be done very simply by adding a "Loader customLoader" field (with its public getter/setter) in the org.hibernate.search.query.FullTextQueryImpl class and by modifying the getLoader() method such as: private Loader getLoader(Session session, SessionFactoryImplementor sessionFactoryImplementor) { if (customLoader!=null) { customLoader.init(session, sessionFactoryImplementor); return customLoader; } ... } After this modification, the programmer can design its own Loader which implements whatever loading strategy. For the example above, the Loader.load(EntityInfo[]) method may looks for each EntityInfo.id in the initially obtained List<MyObject> "list". There is a workaround: copy the full source code of FullTextQueryImpl and add the described modifications. -- 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

14 years, 4 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-431) More details in documentation about MassIndexer

by Sanne Grinovero (JIRA)

More details in documentation about MassIndexer ----------------------------------------------- Key: HSEARCH-431 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-431 Project: Hibernate Search Issue Type: Task Components: documentation Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.2.0.Beta3 Add the new diagram Emmanuel has drawn with explanations about the different stages and pipelines of MassIndexer. -- 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

14 years, 4 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-152) Consider using SnapshotDeletionPolicy for hot backup instead of the old locking scheme

by Emmanuel Bernard (JIRA)

Consider using SnapshotDeletionPolicy for hot backup instead of the old locking scheme -------------------------------------------------------------------------------------- Key: HSEARCH-152 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-152 Project: Hibernate Search Issue Type: New Feature Components: directory provider Reporter: Emmanuel Bernard Not sure it's really interesting in our environment though -- 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

14 years, 4 months

2
11
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-376) Delegate search to remote nodes and aggregate

by Emmanuel Bernard (JIRA)

Delegate search to remote nodes and aggregate --------------------------------------------- Key: HSEARCH-376 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-376 Project: Hibernate Search Issue Type: New Feature Reporter: Emmanuel Bernard This would require to - discover the participating nodes - replace the IndexReaders with Searchable (for some valid reasons I chose not to initially) - use a ParallelMultiIndexSearcher - expose IndexSearcher remotely. will be be useful for infinispan -- 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

14 years, 4 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-336) Create a DirectoryProvider for InstantiatedIndex

by Sanne Grinovero (JIRA)

Create a DirectoryProvider for InstantiatedIndex ------------------------------------------------ Key: HSEARCH-336 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-336 Project: Hibernate Search Issue Type: New Feature Components: directory provider Reporter: Sanne Grinovero Assignee: Sanne Grinovero have an option to copy startup data from at startup (like clone a FSDirectory) ? -- 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

14 years, 4 months

3
12
0 / 0

[Hibernate-JIRA] Created: (HHH-4601) implement orphanRemoval for *ToMany and OneToOne

by Emmanuel Bernard (JIRA)

implement orphanRemoval for *ToMany and OneToOne ------------------------------------------------ Key: HHH-4601 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4601 Project: Hibernate Core 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

14 years, 4 months

5
9
0 / 0

[Hibernate-JIRA] Created: (HHH-2459) Problem with <parent> for 2+ levels of components

by Kevin Bragh (JIRA)

Problem with <parent> for 2+ levels of components ------------------------------------------------- Key: HHH-2459 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2459 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.2 Environment: Hibernate 3.2.2, Tested on PostgreSQL and HSQL Reporter: Kevin Bragh Attachments: test.zip I have tested several scenarios similar to the above, and I have searched and posted to the forum with no response. I have attached the faulty code to the thread. I have a main class (A) with 3 components recusively included as follows: A -> B -> C <-> D In the case above, D has a <parent> property to C. While loading an instance of A, it seems that D.setC(...) is called with the value of the main class A, and not of parent C. I don't know if this is a bug, or if parent is not recusively supported. Any help is appreciated. Thks, K. NB: I have tried many different examples (with list and composite-element, etc.) and they all fail with 2+ levels of recursion. Log ----- 2007-03-01 14:53:07,843 DEBUG [org.hibernate.impl.SessionImpl] - <opened session at timestamp: 4803613441277952> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.transaction.JDBCTransaction] - <begin> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.jdbc.ConnectionManager] - <opening JDBC connection> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <total checked-out connections: 0> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <using pooled JDBC connection, pool size: 0> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.transaction.JDBCTransaction] - <current autocommit status: false> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction begin> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.DefaultSaveOrUpdateEventListener] - <saving transient instance> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.AbstractSaveEventListener] - <saving [test.hibernate.recurse.A#<null>]> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.AbstractSaveEventListener] - <executing insertions> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.engine.Versioning] - <using initial version: 0> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Inserting entity: test.hibernate.recurse.A (native id)> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Version: 0> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.SQL] - <insert into TEST_A (NO_VERSION, VAL, VAL_B, VAL_C, VAL_D, UID) values (?, ?, ?, ?, ?, null)> Hibernate: insert into TEST_A (NO_VERSION, VAL, VAL_B, VAL_C, VAL_D, UID) values (?, ?, ?, ?, ?, null) 2007-03-01 14:53:07,859 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Dehydrating entity: [test.hibernate.recurse.A#<null>]> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 1> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 2> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 3> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 4> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 5> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.SQL] - <call identity()> Hibernate: call identity() 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.id.IdentifierGeneratorFactory] - <Natively generated identity: 1> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <flushing session> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <processing flush-time cascades> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <dirty checking collections> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushing entities and processing referenced collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Processing unreferenced collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Scheduling collection removes/(re)creates/updates> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <listing entities:> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <test.hibernate.recurse.A{val=0, b=component[valB,c]{valB=0, c=component[valC,d]{d=component[valD]{valD=0}, valC=0}}, id=1, version=0}> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <executing flush> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <post flush> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <commit> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <automatically flushing session> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <flushing session> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <processing flush-time cascades> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <dirty checking collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushing entities and processing referenced collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Processing unreferenced collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Scheduling collection removes/(re)creates/updates> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <listing entities:> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <test.hibernate.recurse.A{val=0, b=component[valB,c]{valB=0, c=component[valC,d]{d=component[valD]{valD=0}, valC=0}}, id=1, version=0}> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <executing flush> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <post flush> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <before transaction completion> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <before transaction completion> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <committed JDBC Connection> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction completion> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <aggressively releasing JDBC connection> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <closing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <returning connection to pool, pool size: 1> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <after transaction completion> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <closing session> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <connection already null in cleanup : no action> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <opened session at timestamp: 4803613441597440> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <begin> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <opening JDBC connection> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <total checked-out connections: 0> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <using pooled JDBC connection, pool size: 0> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <current autocommit status: false> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction begin> 2007-03-01 14:53:07,906 DEBUG [org.hibernate.engine.query.QueryPlanCache] - <unable to locate HQL query plan in cache; generating (from test.hibernate.recurse.A)> 2007-03-01 14:53:07,921 DEBUG [org.hibernate.jdbc.ConnectionManager] - <running Session.finalize()> 2007-03-01 14:53:08,000 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <parse() - HQL: from test.hibernate.recurse.A> 2007-03-01 14:53:08,015 DEBUG [org.hibernate.hql.ast.AST] - <--- HQL AST --- \-[QUERY] 'query' \-[SELECT_FROM] 'SELECT_FROM' \-[FROM] 'from' \-[RANGE] 'RANGE' \-[DOT] '.' +-[DOT] '.' | +-[DOT] '.' | | +-[IDENT] 'test' | | \-[IDENT] 'hibernate' | \-[IDENT] 'recurse' \-[IDENT] 'A' > 2007-03-01 14:53:08,031 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors> 2007-03-01 14:53:08,078 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select << begin [level=1, statement=select]> 2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.ast.tree.FromElement] - <FromClause{level=1} : test.hibernate.recurse.A (no alias) -> a0_> 2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select : finishing up [level=1, statement=select]> 2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.ast.HqlSqlWalker] - <processQuery() : ( SELECT ( FromClause{level=1} TEST_A a0_ ) )> 2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.HqlSqlWalker] - <Derived SELECT clause created.> 2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.util.JoinProcessor] - <Using FROM fragment [TEST_A a0_]> 2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select >> end [level=1, statement=select]> 2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.AST] - <--- SQL AST --- \-[SELECT] QueryNode: 'SELECT' querySpaces (TEST_A) +-[SELECT_CLAUSE] SelectClause: '{derived select clause}' | +-[SELECT_EXPR] SelectExpressionImpl: 'a0_.UID as UID0_' {FromElement{explicit,not a collection join,not a fetch join,fetch non-lazy properties,classAlias=null,role=null,tableName=TEST_A,tableAlias=a0_,origin=null,colums={,className=test.hibernate.recurse.A}}} | \-[SQL_TOKEN] SqlFragment: 'a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_' \-[FROM] FromClause: 'from' FromClause{level=1, fromElementCounter=1, fromElements=1, fromElementByClassAlias=[], fromElementByTableAlias=[a0_], fromElementsByPath=[], collectionJoinFromElementsByPath=[], impliedElements=[]} \-[FROM_FRAGMENT] FromElement: 'TEST_A a0_' FromElement{explicit,not a collection join,not a fetch join,fetch non-lazy properties,classAlias=null,role=null,tableName=TEST_A,tableAlias=a0_,origin=null,colums={,className=test.hibernate.recurse.A}} > 2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors> 2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <HQL: from test.hibernate.recurse.A> 2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <SQL: select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_> 2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors> 2007-03-01 14:53:08,140 DEBUG [org.hibernate.engine.query.HQLQueryPlan] - <HQL param location recognition took 0 mills (from test.hibernate.recurse.A)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.query.QueryPlanCache] - <located HQL query plan in cache (from test.hibernate.recurse.A)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.query.HQLQueryPlan] - <find: from test.hibernate.recurse.A> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.QueryParameters] - <named parameters: {}> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.SQL] - <select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_> Hibernate: select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_ 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open ResultSet (open ResultSets: 0, globally: 0)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <processing result set> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <result set row: 0> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.LongType] - <returning '1' as column: UID0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <result row: EntityKey[test.hibernate.recurse.A#1]> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <Initializing object from ResultSet: [test.hibernate.recurse.A#1]> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Hydrating entity: [test.hibernate.recurse.A#1]> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: NO2_0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL4_0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL5_0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL6_0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.TwoPhaseLoad] - <Version: 0> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <done processing result set (1 rows)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close ResultSet (open ResultSets: 1, globally: 1)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <total objects hydrated: 1> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.TwoPhaseLoad] - <resolving associations for [test.hibernate.recurse.A#1]> 2007-03-01 14:53:08,156 ERROR [org.hibernate.property.BasicPropertyAccessor] - <IllegalArgumentException in class: test.hibernate.recurse.D, setter method of property: c> 2007-03-01 14:53:08,156 ERROR [org.hibernate.property.BasicPropertyAccessor] - <expected type: test.hibernate.recurse.C, actual value: test.hibernate.recurse.A> Exception stack trace ----------------------------- Exception in thread "main" org.hibernate.PropertyAccessException: IllegalArgumentException occurred while calling setter of test.hibernate.recurse.D.c at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:104) at org.hibernate.tuple.PojoComponentTuplizer.setParent(PojoComponentTuplizer.java:132) at org.hibernate.type.ComponentType.instantiate(ComponentType.java:438) at org.hibernate.type.ComponentType.resolve(ComponentType.java:524) at org.hibernate.type.ComponentType.resolve(ComponentType.java:528) at org.hibernate.type.ComponentType.resolve(ComponentType.java:528) at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:113) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842) at org.hibernate.loader.Loader.doQuery(Loader.java:717) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:223) at org.hibernate.loader.Loader.doList(Loader.java:2147) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2026) at org.hibernate.loader.Loader.list(Loader.java:2021) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:369) at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:298) at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:137) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1014) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) at test.hibernate.recurse.Main.main(Main.java:67) Caused by: java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:42) ... 18 more -- 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

14 years, 4 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-183) @IndexedEmbedded(prefix="") should either be forbidden or fixed with duplicate ID fields

by Stephane Epardaud (JIRA)

@IndexedEmbedded(prefix="") should either be forbidden or fixed with duplicate ID fields ---------------------------------------------------------------------------------------- Key: HSEARCH-183 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-183 Project: Hibernate Search Issue Type: Improvement Components: mapping Affects Versions: 3.0.1.GA Reporter: Stephane Epardaud If all my entities have their ID property named "id" and they use @IndexedEmbedded(prefix="") then there will be several fields named "id" per document. This results in very unfortunate behaviour when indexes are updated because this id is then used by HS to remove Lucene documents, so instead of removing only the one document we are updating, HS removes all documents whose ID have been embedded in the index. We use prefix="" in order to accumulate embedded entities' "text" fields into the root entity so that we can search on any "text" field, embedded or not. This is required because there seems to be no support for a term wildcard such as "*.text:foo" which would search on any term ending by ".text" for the string "foo". Either prefix="" is supported, and this behaviour should be changed, or at the very least trigger a visible warning, or it is not supported and it should be documented and an exception should be thrown. Since it is behaviour I need, I favour supporting it, so I've patched DocumentBuilder to store the ID of the root entity in a special field like _hibernate_class, so that when we update the index only the appropriate entity index document is removed. This works well, but has the side-effect of ignoring the name of the ID as specified in @DocumentId. An alternative would be to still store the root ID is a "special" field, and keep storing the ID under a field name as specified by the user. As long as we only use the "special" ID for index updating all will work well. I can produce both patches and documentation if you agree (and choose). -- 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

14 years, 4 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-4108) Invalid result in native query

by Oleksandr Fedorenko (JIRA)

Invalid result in native query ------------------------------ Key: HHH-4108 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4108 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.2 Environment: 3.3.2, MySQL 5.1 Reporter: Oleksandr Fedorenko Priority: Critical We have the native query executed with entity manager, example : Query query = entityManager.createNativeQuery(sqlString); List result = query.getResultList(); The returned result is an array of objects that has projection values. When table column has type CHAR(N) , the result value is always instance of java.lang.Character and here we have only first character of database field and the rest characters are lost. It is supposed to have result of java.lang.String class here. When the column is altered to VARCHAR(N), the result is java.lang.String. -- 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

14 years, 5 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3684) Sybase - Setting FetchMode.JOIN fails if there are 3 or more joins and at least one join involves a union

by Gail Badner (JIRA)

Sybase - Setting FetchMode.JOIN fails if there are 3 or more joins and at least one join involves a union --------------------------------------------------------------------------------------------------------- Key: HHH-3684 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3684 Project: Hibernate Core Issue Type: Bug Components: core Reporter: Gail Badner Assignee: Gail Badner This is reproduced by UnionSubclassTest.testUnionSubclassFetchMode().. This may be due to a bug in Sybase. A similar problem is discussed here: http://www.forumtopics.com/busobj/viewtopic.php?p=442226&sid=40bd96248c52... For the unit test mentioned above, changing: select ... from ( select ... from humans union select ... from employees ) this_ inner join locations location2_ on this_.location=location2_.id left outer join ( select ... from employees union select ... from humans union select ... from aliens ) beings3_ on location2_.id=beings3_.location : to: select ... from ( select ... from humans union select ... from employees ) this_ inner join (locations location2_ left outer join ( select ... from employees union select ... from humans union select ... from aliens ) beings3_ on location2_.id=beings3_.location) : on this_.location=location2_.id fixes the problem. This changer is similar to what is documented for a "right-nested outer join" at http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc32300.150.... -- 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

14 years, 5 months

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-5086) "ambiguous column" SQL errors in Hibernate 3.5.0 Final

by dnalos (JIRA)

"ambiguous column" SQL errors in Hibernate 3.5.0 Final ------------------------------------------------------ Key: HHH-5086 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5086 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-Final Environment: Java JDK 1.6.0_19 Hibernate Core 3.5.0 Final hibernate-jpa-2.0-api-1.0.0.Final.jar mysql-connector-java-5.1.10-bin.jar Reporter: dnalos Attachments: HibernateAmbiguousTest.zip After update Hibernate Core to 3.5, we get some Exception like this: Column '_value' in field list is ambiguous (JDBCExceptionReporter.java:101) We create a testcase for you, and the Exception from the testcase: ERROR 15:39:28 0 Column '_value' in field list is ambiguous (JDBCExceptionReporter.java:101) org.hibernate.exception.ConstraintViolationException: could not load an entity: [Invoice#401] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.loader.Loader.loadEntity(Loader.java:1937) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:86) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:76) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3270) at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:496) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:477) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:227) at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:285) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:152) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:1080) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:997) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:990) at HibernateAmbiguousTest.testAmbiguous(HibernateAmbiguousTest.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Column '_value' in field list is ambiguous at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.Util.getInstance(Util.java:381) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1015) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3558) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3490) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2109) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2648) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2077) at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2228) at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:76) at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208) at org.hibernate.loader.Loader.getResultSet(Loader.java:1849) at org.hibernate.loader.Loader.doQuery(Loader.java:718) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:270) at org.hibernate.loader.Loader.loadEntity(Loader.java:1933) ... 34 more -- 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

14 years, 5 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5206) mapping TextType with outer join on oracle causes "Stream has already been closed" error

by Strong Liu (JIRA)

mapping TextType with outer join on oracle causes "Stream has already been closed" error ---------------------------------------------------------------------------------------- Key: HHH-5206 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5206 Project: Hibernate Core Issue Type: Bug Components: build Affects Versions: 3.5.1, 3.5.0-Final Reporter: Strong Liu Assignee: Gail Badner org.hibernate.test.onetoone.formula.OneToOneFormulaTest.testOneToOneFormula() fails on oracle {quote} http://www.jroller.com/agrebnev/entry/hibernate_dbms_portability_tips_tricks Instead BLOB I use "long raw". It is a VARBINARY hibernate type. Here I faced with another Oracle problem "java.sql.SQLException: Stream has already been closed" accessing long raw. The problem is that "The Oracle JDBC driver automatically closes any pending inputstreams whenever another database access is made". It means you should get binary data from result set before all other types. In terms of Hibernate the mapping of binary field should be last. And please keep in your mind that you should disable outer join fetching with class which contains this field. {quote} -- 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

14 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-461) Improve support for all language specific snowball Analyzers in Lucene/contrib

by Sanne Grinovero (JIRA)

Improve support for all language specific snowball Analyzers in Lucene/contrib ------------------------------------------------------------------------------ Key: HSEARCH-461 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-461 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 3.3.0 For Lucene 3.1 Robert Muir did a great job of standardazing and cleaning Analyzers in contrib with many languages support (wrapping snowball analyzers); I'd like to look into having some helper in Hibernate Search in setting them up all to be available as analyzers and couple to entities in some clever way. -- 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

14 years, 5 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-56) Updating a collection does not reindex

by Emmanuel Bernard (JIRA)

Updating a collection does not reindex -------------------------------------- Key: HSEARCH-56 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-56 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.0.0.beta1 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

14 years, 5 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3220) Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions

by Dan Bisalputra (JIRA)

Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions ----------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3220 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3220 Project: Hibernate3 Issue Type: Patch Components: core Affects Versions: 3.2.6 Environment: Hibernate 3.2.6, Apache Derby on Mac OSX & PC Reporter: Dan Bisalputra Priority: Minor When performing a query in a stateless session, the query loads objects in a two-phase process in which a temporary persistence context is populated with empty objects in the first phase, then the objects' member data are read from the database in the second phase. If one of the objects contains an association or a collection, it performs a recursive call to the session's get() method. The get() method clears the temporary persistence context, so if the parent object contains any other associations to be read in the second phase, Hibernate throws an assertion because they are not found in the persistence context. This patch solves the problem by only clearing the persistence context when the recursion ends. It passes all the unit tests for our application, but I have not tested it with any of the Hibernate unit tests. -- 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

14 years, 5 months

8
17
0 / 0

[Hibernate-JIRA] Created: (ANN-720) cant bind a child using mappedby relating to a parent attribute(polymorphism)

by Nino Martinez (JIRA)

cant bind a child using mappedby relating to a parent attribute(polymorphism) ----------------------------------------------------------------------------- Key: ANN-720 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-720 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.3.1.GA Environment: osx 10.4, java 1.5 Reporter: Nino Martinez Attachments: JPA101.zip This is pseudo class hieracy @Entity @Inheritance(strategy = InheritanceType.JOINED) Mammal { @ManyToOne Person owner; } @Entity Cat extends Mammal Person{ @Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN) @OneToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REMOVE }, mappedBy = "owner") private List<Cat> cats = new ArrayList<Cat>(); } it gives the error mission property: javax.persistence.PersistenceException: org.hibernate.AnnotationException: mappedBy reference an unknown target entity property: Cat.owner in Person.cats This is the related thread on hibernate forum: http://forum.hibernate.org/viewtopic.php?p=2380570#2380570 I can confirm that the same example does work when using OpenJPA as a provider. Please see attached project for reference. Please do not hesitate me if you have questions. -- 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

14 years, 5 months

7
13
0 / 0

[Hibernate-JIRA] Created: (HHH-3637) Union in where doesn't works for Sybase, need to evict test case

by Juraci Paixao Krohling (JIRA)

Union in where doesn't works for Sybase, need to evict test case ---------------------------------------------------------------- Key: HHH-3637 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3637 Project: Hibernate Core Issue Type: Improvement Components: testsuite Environment: Sybase ASE 15.0.2 Reporter: Juraci Paixao Krohling Assignee: Juraci Paixao Krohling It seems that Sybase doesn't supports UNION inside WHERE clauses, causing the test DynamicFilterTest#testSqlSyntaxOfFiltersWithUnions to fail. The scenario for this test case is not described in the documentation, but I would expect it to work: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.... The query is: select category0_.CAT_ID as CAT1_6_, category0_.name as name6_, category0_.eff_start_dt as eff3_6_, category0_.eff_end_dt as eff4_6_ from CATEGORY category0_ where 'abc' in ( select d.reg from department d where ( d.dept_id=123 ) union select p.name from sales_person p ) If executed only the queries from inside the where clause (the two selects with union), it works as expected. Also, if removed the union and one of the queries inside the where, it works as expected. So, the problem happens only when using union inside a where clause. For now, I'd suggest to evict this test for Sybase. -- 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

14 years, 5 months

5
10
0 / 0

[Hibernate-JIRA] Created: (HHH-2447) Connection leak if logAndClearWarnings throws

by Jeppe N. Madsen (JIRA)

Connection leak if logAndClearWarnings throws ---------------------------------------------- Key: HHH-2447 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2447 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3, 3.2.2 Environment: Database product name : DB2/NT Database product version : SQL08025 JDBC driver name : IBM DB2 JDBC Universal Driver Architecture Hibernate 3.1.3 (seems to exist in 3.2.2 as well) JDBC driver version : 2.9.31 Reporter: Jeppe N. Madsen Priority: Minor In ConnectionManager.closeConnection, logAndClearWarnings is called before connection.close() is called. If this call throws an exception, the connection is never closed. We have observed that DB2 sometimes throws an Error because the SQLWarning chain is wrong: [14-02-07 11:36:30:889 CET] 10b0b533 WebGroup E SRVE0026E: [Servlet Error]-[SQLWarning chain holds value that is not a SQLWarning]: java.lang.Error: SQLWarning chain holds value that is not a SQLWarning at java.sql.SQLWarning.getNextWarning(SQLWarning.java:109) at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:50) at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:33) at org.hibernate.util.JDBCExceptionReporter.logAndClearWarnings(JDBCExceptionReporter.java:22) at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:443) at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:379) at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:318) at org.hibernate.impl.SessionImpl.close(SessionImpl.java:293) -- 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

14 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-318) Hibernate Validator doesn't compiles in OpenJDK 6

by Juraci Paixao Krohling (JIRA)

Hibernate Validator doesn't compiles in OpenJDK 6 ------------------------------------------------- Key: HV-318 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-318 Project: Hibernate Validator Issue Type: Bug Components: build Environment: RHEL5, OpenJDK6 Reporter: Juraci Paixao Krohling Assignee: Hardy Ferentschik /qa/hudson_ws/workspace/hibernate-validator-trunk/jdk/openjdk-local/label/RHEL5_any/trunk/hibernate-validator/src/test/java/org/hibernate/validator/util/TestUtil.java:[66,30] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>javax.validation.bootstrap.ProviderSpecificBootstrap<T> required: java.lang.Object -- 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

14 years, 5 months

3
12
0 / 0

[Hibernate-JIRA] Created: (HHH-4015) one-to-one: foreign key: save Problem

by Sandeep Vaid (JIRA)

one-to-one: foreign key: save Problem ------------------------------------- Key: HHH-4015 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4015 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.6 Reporter: Sandeep Vaid Priority: Critical I have one-to-one relationship between class A and class B <class name="A" table="TEMPA" > <id name="aaId" type="string" column="AID" length="10"> <generator class="assigned"></generator> </id> <one-to-one name="b" class="B" constrained="true" outer-join="false" cascade="save-update" /> </class> <class name="B" table="TEMPB" lazy="true"> <id name="baId" type="string" column="BID" length="10"> <generator class="foreign"> <param name="property">a</param> </generator> </id> <one-to-one name="a" class="A" /> </class> Problem 1: When i try to save A, it fires : insert into HBLEARN1.TEMPB (BID) values ('1') and throws error : The insert or update value of the FOREIGN KEY "TEMPB.CC1246876555824" is not equal to any value of the parent key of the parent table. SQLSTATE=23503 Why it is first trying to save 'B' instead of 'A' first ? Problem 2: With this mapping, if i set <property name="hibernate.hbm2ddl.auto">create</property> in hibernate.cfg.xml, It generates TEMPA whose aaId is the foreign key referencing TEMPB. This is also incorrect.. -- 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

14 years, 5 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2075) many-to-one in a properties element causes strange PropertyValueException on flush

by Josh Moore (JIRA)

many-to-one in a properties element causes strange PropertyValueException on flush ---------------------------------------------------------------------------------- Key: HHH-2075 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2075 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr4 Environment: HSQLDB Hibernate r10478 Reporter: Josh Moore Attachments: exception.txt, log.txt, properties.zip Full test directory zip (org/hibernate/test/properties) attached. But to summarize, the following test will fail on flush after a simple merge. The exception thrown says that Pixels.sizeC is null -- though it's clearly set in the test case. <code> Image i = new Image(); Pixels p = new Pixels(); p.setSizeC(new Integer(2)); p.setImage(i); // This calls i.getPixels().add(p) // i.setPixels(null); // This makes it work. Session s = openSession(); Transaction t = s.beginTransaction(); // s.merge(i); // This makes it work. p = (Pixels) s.merge(p); // This fails with the exception below. t.commit(); s.close(); </code> The properties element in question is: <code> <properties name="defaultPixelsTag"> <property name="defaultPixels" type="java.lang.Boolean"/> <many-to-one name="image" class="Image" column="image" not-null="true" unique="false" insert="true" update="true" cascade="lock,merge,persist,replicate,refresh,save-update" /> </properties> </code> The reverse side is: <code> <set name="pixels" lazy="true" inverse="true" cascade="lock,merge,persist,replicate,refresh,save-update"> <key column="image" not-null="false"/> <one-to-many class="Pixels"/> </set> </code> -- 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

14 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3102) Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()

by Paul Cowan (JIRA)

Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate() -------------------------------------------------------------------------------- Key: HHH-3102 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3102 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.4.sp1 Reporter: Paul Cowan Priority: Minor Attachments: HibernateKeyPoolTest.java Hi all, Not 100% sure if you'd call this a 'bug' as I'm not sure if the correct behaviour is actually specified anywhere. It's certainly oddly inconsistent though. Please find attached a standalone test case (requires HSQLDB on the classpath; amend setUp() if you need to use something else) which models a parent-child mapping between 'Mouth' (1) and 'Teeth' (many). The Mouth -> Teeth relationship is bidirectional, with CascadeType.ALL on the single-valued end. Both Mouth and Tooth use a @GenericGenerator, which simply allocates integers from a static keypool. A mouth with one tooth is created, saveOrUpdate()d, session is flushed, a new tooth is added, mouth is saveOrUpdate()d again, and session is again flushed. The debug output is as follows: *** After creation Mouth (id=null) has teeth [canine(id=null)] *** Save Mouth (id=1) has teeth [canine(id=2)] *** Flush Hibernate: insert into Mouth (id) values (?) Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?) Mouth (id=1) has teeth [canine(id=2)] *** Add new Mouth (id=1) has teeth [canine(id=2), molar(id=null)] *** Save again Mouth (id=1) has teeth [canine(id=2), molar(id=null)] *** Flush again Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?) Mouth (id=1) has teeth [canine(id=2), molar(id=3)] As you can see, when initially created the IDs for the mouth and tooth are both null (obviously correct). The saveOrUpdate() on the Mouth object then generates identifier values, even though no DB write has been done yet (the .flush()). So far, so good. However, when a NEW transient Tooth instance ("molar") is added to the Mouth, and saveOrUpdate() is called once more, the id generator is not invoked, UNTIL such time as the session is flushed. While I guess it's fine for an object in the 'persistent' state not to actually have an identifier until flush-time (e.g. when using DB-side IDENTITY-type generation), it just seems inconsistent that with a @GenericGenerator the behaviour would vary depending on whether the PARENT object was already persistent or not. There are some obvious workarounds (e.g. flush the session upon saving, or save the child entity first independently) but I thought I'd clarify if this behaviour is by design or not and suggest that this be made consistent. -- 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

14 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2166) Long "in" lists in queries results in a Java stack overflow exception.

by Philip R. "Pib" Burns (JIRA)

Long "in" lists in queries results in a Java stack overflow exception. ---------------------------------------------------------------------- Key: HHH-2166 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2166 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: Hibernate 3.2.0.cr3 through 3.2.0.ga (at least). Any standard deployment of Sun's JVM on Windows, Linux, or Mac OS X (and presumably other platforms like Solaris) Reporter: Philip R. "Pib" Burns Attachments: NodeTraverser.java With Hibernate 320ga a long "in" list can result in a stack overflow error during the parsing stage. For example, a query element like where x in (:x) or a manually constructed where x in (1,2,3 .....) can generate a stack overflow if the number of elements referenced by x exceeds a number dependent upon the amount of available stack space. For many JVMs, the limit is between 9,000 and 10,000 assuming a relatively empty stack at the point of query execution. We have applications which occasionally use lists several times this size. The stack overflow occurs in org.hibernate.hql.ast.util.NodeTraverser which uses a recursive algorithm to walk a parse tree. Long "in" lists generate a subtree of depth about equal to the number of elements in the list. A sufficiently long list results in a stack overflow when NodeTraverser's internal method visitDepthFirst calls itself too many times. The solution is to replace the recursive tree walking strategy with an iterative one that does not use up stack space. I am attaching the source for a replacement version of . NodeTraverser which implements the iterative tree walking method. -- 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

14 years, 5 months

11
41
0 / 0

[Hibernate-JIRA] Created: (HHH-4577) 2L query cache: Low performance of flush and commit due many unnecessary (pre)invalidate calls on UpdateTimestampsCache

by Guenther Demetz (JIRA)

2L query cache: Low performance of flush and commit due many unnecessary (pre)invalidate calls on UpdateTimestampsCache ----------------------------------------------------------------------------------------------------------------------- Key: HHH-4577 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4577 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.2 Environment: Hibernate 3.3.2GA with JBossCache3.2.1.GA as 2L-cache provider SQLServer2008 Reporter: Guenther Demetz Analyzing what our application is mainly doing during flush/commit, we saw that very often the concerning thread is executing in jbosscache stuff (see 2 sample stacktraces below). Analyzing the code we discovered that, if doing 1000 inserts for a determinate entity: -on flush UpdateTimestampsCache.preinvalidate() is called 1000 times for the same space (=table) -on commit UpdateTimestampsCache.invalidate() is called another 1000 times again for the same space (=table) It would be much smarter to collect the interested spaces once per flush and once per commit and then execute the (pre)invalidate once per single space. In the case above it would reduce the calls to one single UpdateTimestampsCache.preinvalidate()call on flush and one single UpdateTimestampsCache.invalidate() on commit. For the commit the enhancement could be following: ActionQueue.java: public void afterTransactionCompletion(boolean success) { int size = executions.size(); final boolean invalidateQueryCache = session.getFactory().getSettings().isQueryCacheEnabled(); Set<Serializable> spaces = invalidateQueryCache ? new HashSet<Serializable>() : null; try { for ( int i = 0; i < size; i++ ) { try { Executable exec = ( Executable ) executions.get( i ); if ( invalidateQueryCache ) { Serializable[] nspaces = exec.getPropertySpaces(); for (int j=0; j < nspaces.length; j++) spaces.add(nspaces[j]); } exec.afterTransactionCompletion( success ); } catch ( CacheException ce ) { log.error( "could not release a cache lock", ce ); // continue loop } catch ( Exception e ) { throw new AssertionFailure( "Exception releasing cache locks", e ); } } } finally { session.getFactory().getUpdateTimestampsCache().invalidate(spaces.toArray(new Serializable[]{})); } executions.clear(); } Stack traces: java.lang.Thread.isInterrupted(Native Method) java.lang.Thread.interrupted(Thread.java:873) java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1134) java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:312) java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:241) org.jboss.cache.RegionImpl.registerEvictionEvent(RegionImpl.java:249) org.jboss.cache.RegionImpl.registerEvictionEvent(RegionImpl.java:234) org.jboss.cache.interceptors.EvictionInterceptor.registerEvictionEventToRegionManager(EvictionInterceptor.java:252) org.jboss.cache.interceptors.EvictionInterceptor.visitPutKeyValueCommand(EvictionInterceptor.java:109) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:102) org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301) org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283) org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:119) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178) org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287) org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:555) org.hibernate.cache.jbc2.util.CacheHelper.put(CacheHelper.java:212) org.hibernate.cache.jbc2.timestamp.TimestampsRegionImpl.put(TimestampsRegionImpl.java:128) org.hibernate.cache.UpdateTimestampsCache.preinvalidate(UpdateTimestampsCache.java:70) - locked org.hibernate.cache.UpdateTimestampsCache@1afcaae org.hibernate.engine.ActionQueue.execute(ActionQueue.java:275) org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167) org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) Stack trace: java.lang.Thread.isInterrupted(Native Method) java.lang.Thread.interrupted(Thread.java:873) java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1158) java.util.concurrent.locks.ReentrantLock.tryLock(ReentrantLock.java:416) org.jboss.cache.util.concurrent.locks.AbstractSharedLockContainer.acquireLock(AbstractSharedLockContainer.java:94) org.jboss.cache.lock.MVCCLockManager.lockAndRecord(MVCCLockManager.java:133) org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:157) org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:217) org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186) org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:101) org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301) org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283) org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:119) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178) org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287) org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:555) org.hibernate.cache.jbc2.util.CacheHelper.put(CacheHelper.java:212) org.hibernate.cache.jbc2.timestamp.TimestampsRegionImpl.put(TimestampsRegionImpl.java:128) org.hibernate.cache.UpdateTimestampsCache.invalidate(UpdateTimestampsCache.java:85) - locked org.hibernate.cache.UpdateTimestampsCache@1afcaae org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:202) -- 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

14 years, 5 months

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3850) org.jboss.cache.lock.TimeoutException: failure acquiring lock, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)

by wu bin (JIRA)

org.jboss.cache.lock.TimeoutException: failure acquiring lock, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3850 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3850 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.2.6 Environment: linux , oracle 9.2 jboss 4.2.3 Reporter: wu bin we use hibernate and jboss tree cache in jboss 4.2.3 in lnux. we only have 1 node in the cluster. we met this exception: 19:00:58,515 ERROR [TxInterceptor] method invocation failed org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) at org.jboss.cache.Node.acquire(Node.java:533) at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410) at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568) at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472) at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338) at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183) at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919) at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196) at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777) at org.jgroups.JChannel.up(JChannel.java:1091) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382) at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158) at org.jgroups.stack.UpHandler.run(Protocol.java:60) Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: [] Write lock owner: Thread[http-8443-14,5,jboss] (caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)) at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206) at org.jboss.cache.Node.acquireWriteLock(Node.java:562) at org.jboss.cache.Node.acquire(Node.java:509) ... 31 more 19:00:58,516 ERROR [TxInterceptor] prepare method invocation failed java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:591) at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472) at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338) at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183) at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919) at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196) at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777) at org.jgroups.JChannel.up(JChannel.java:1091) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382) at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158) at org.jgroups.stack.UpHandler.run(Protocol.java:60) Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) at org.jboss.cache.Node.acquire(Node.java:533) at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410) at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568) ... 22 more Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: [] Write lock owner: Thread[http-8443-14,5,jboss] (caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)) at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206) at org.jboss.cache.Node.acquireWriteLock(Node.java:562) at org.jboss.cache.Node.acquire(Node.java:509) ... 31 more 19:00:58,516 WARN [TreeCache] replication failure with method_call prepare; id:10; Args: ( arg[0] = GlobalTransaction:<16.173.241.57:9242>:119 ...) exception java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:591) at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472) at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338) at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183) at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919) at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196) at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777) at org.jgroups.JChannel.up(JChannel.java:1091) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382) at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158) at org.jgroups.stack.UpHandler.run(Protocol.java:60) Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) at org.jboss.cache.Node.acquire(Node.java:533) at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410) at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568) ... 22 more Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: [] Write lock owner: Thread[http-8443-14,5,jboss] (caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)) at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206) at org.jboss.cache.Node.acquireWriteLock(Node.java:562) at org.jboss.cache.Node.acquire(Node.java:509) ... 31 more -- 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

14 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4055) make UpdateTimestampsCache pluggable, like QueryCache

by A. R. (JIRA)

make UpdateTimestampsCache pluggable, like QueryCache ----------------------------------------------------- Key: HHH-4055 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4055 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.2 Environment: all Reporter: A. R. According to https://www.hibernate.org/213.html, one can plug-in one's own query cache using hibernate.cache.query_cache_factory, e.g. to chose a cache strategy that is not based on updateTimestamps. However, Hibernate's SessionFactoryImpl will always create an UpdateTimestampsCache if the Query Cache is enabled, even for custom Query Caches. This UpdateTimestampsCache then is always used in org.hibernate.engine.ActionQueue.execute() and afterTransactionCompletion(). Since the UpdateTimestampsCache is synchronized, this can cause bottlenecks when many threads change things (see http://tech.puredanger.com/2009/07/10/hibernate-query-cache/).. Please make the UpdateTimestampsCache also pluggable, so that one can truly and completely plug one's own Query Cache without using a Update-Timestamps or with a custom UpdateTimestampCache. -- 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

14 years, 5 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2305) refresh throws exception when database has been altered with a delete

by Markus Heiden (JIRA)

refresh throws exception when database has been altered with a delete --------------------------------------------------------------------- Key: HHH-2305 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2305 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Environment: Hibernate 3.2.1, Oracle 9.2 Reporter: Markus Heiden Attachments: hibernate.zip First I save an entity with a collection of cascading entities in it and flush. Then I delete these cascaded entities with a sql query. When I now do a refresh on the entity an exception is thrown, because the cascaded entities couldn't be found in the database. I expected these entities to be deleted from the (in memory) collection of the entity instead. Test case is attached. Stacktrace of test case: Hibernate: select c0_.id as id2_0_, c0_.c as c2_0_ from C c0_ where c0_.id=? org.hibernate.UnresolvableObjectException: No row with the given identifier exists: [hibernate.refresh.C#30003] at org.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:42) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:126) at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911) at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894) at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296) at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascade(Cascade.java:130) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99) at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911) at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894) at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296) at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascade(Cascade.java:130) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:39) at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:902) at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:886) at hibernate.refresh.Test.main(Test.java:46) -- 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

14 years, 5 months

5
5
0 / 0

[Hibernate-JIRA] Created: (HV-274) Write a programmatic mapping API for constraint declarations

by Emmanuel Bernard (JIRA)

Write a programmatic mapping API for constraint declarations ------------------------------------------------------------ Key: HV-274 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-274 Project: Hibernate Validator Issue Type: New Feature Reporter: Emmanuel Bernard 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

14 years, 5 months

5
17
0 / 0

[Hibernate-JIRA] Created: (HHH-3360) Custom Oracle Batcher to allow batch updates for versioned data

by Manuel Dominguez Sarmiento (JIRA)

Custom Oracle Batcher to allow batch updates for versioned data --------------------------------------------------------------- Key: HHH-3360 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3360 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.3.0.CR1, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga Environment: Oracle 10g R1, 10g R2, 11g R1 (have not tried previous Oracle versions), 11g R1 drivers (older drivers should also work) Reporter: Manuel Dominguez Sarmiento Priority: Minor Attachments: C3P0OracleBatchingBatcher.java, C3P0OracleBatchingBatcherFactory.java, OracleBatchingBatcher.java, OracleBatchingBatcherFactory.java We have developed a custom Oracle Batcher which allows batching versioned data. The Oracle JDBC driver does not return update counts when using the standard JDBC 2.0 batching mechanism, however the proprietary Oracle batching mechanism allows obtaining the total batch row update count. The update counts are absolutely necessary to detect stale updates. Although it is not exactly the same, the total row update count is actually enough information to be able to batch versioned data and still detect stale updates. We'd like to contribute the attached files. They have a compile time dependency on Oracle JDBC. If this is not acceptable, it could be easily solved by using reflection. Another Batcher is provided for when the Oracle connection is being managed through c3p0 (a common deployment scenario). This has a compile time dependency on c3p0. A few "dirty" tricks were necessary to pull this off without patching other classes. Specifically, it was necessary to override Java private semantics to obtain BasicExpectation.expectedRowCount. This could be easily solved by adding an accessor method to the Expectation interface. There is one issue which we are not completely sure of, however so far we have not found any problems. When the Expectation is NONE, there is no way to check whether the total row count is correct or not, even if other batched updates do have expectations with expected row counts. Our understanding is that actually, since batching requires all statements to be of the same type (since the same PreparedStatement / CallableStatement is being used), then either ALL expectations will be NONE, or all will have an expected row count. We'd welcome comments from the Hibernate team. This could also be probably handled better by improving the Expectation interface. Oracle JDBC docs that explain the Oracle batching model: http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/oraperf.htm#... As expected, implementing this solution has resulted in drastical improvement in batch processing. -- 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

14 years, 5 months

4
11
0 / 0

[Hibernate-JIRA] Created: (ANN-644) @ManyToMany appears to ALWAYS generate a left outer join SQL

by Barry Davies (JIRA)

@ManyToMany appears to ALWAYS generate a left outer join SQL ------------------------------------------------------------ Key: ANN-644 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-644 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.0.ga Reporter: Barry Davies Priority: Minor Attachments: files.zip A collection mapping created using the @ManyToMany JPA annotation appears to create a left outer join SQL regardless of whether the joinColumn or inverseJoinColumn are marked nullable or not. This might be in error. Emmanuel asked for a JIRA issue to be created, so here we are. I have attached some files that can recreate what I believe to be the issue. The forum topic where this was brought up is: http://forum.hibernate.org/viewtopic.php?t=977936 -- 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

14 years, 5 months

3
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2010