[Hibernate-JIRA] Created: (HSEARCH-842) File Leaks - FSMasterDirectoryProvider & Mass indexing
by Johnny B (JIRA)
File Leaks - FSMasterDirectoryProvider & Mass indexing
------------------------------------------------------
Key: HSEARCH-842
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-842
Project: Hibernate Search
Issue Type: Bug
Components: directory provider
Affects Versions: 3.3.0.Final
Environment: Windows/linux Hibernate 3.6.5 , lucene 3.0.3
Reporter: Johnny B
Attachments: fileleaks.zip
Hi Guys,
As already discussed in forum
https://forum.hibernate.org/viewtopic.php?f=9&t=1011938&p=2447638
Basically i notice that the FSMasterDirectoryProvider never releases its file handles even after a full batch index has taken place.
Example
Test case 1
1. Fresh clean index
2. Batch index takes place, all file handles are closed at the end, nothing is open
3. You can batch index as many times as you want but at the end of each batch index no file handles are open.
Test case 2
1. Index exists already, start up application and FSMasterDirectoryProvider opens file handles to existing index
2. Batch index triggered for that index. At the end of the batch index, i notice that the same file file handles are still open as when the app started. This should not be because we have purged the index and carried out a full batch index for it. The index size has now doubled!!!
3. You can carry out as many batch indexes as you want but the very original file handles at start up are always kept open.
Test case is attached and forum description gives better insight as to how i carried out the tests
Cheers,
JB
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[Hibernate-JIRA] Created: (HHH-5775) Support session filters in DML statements
by Jason Clawson (JIRA)
Support session filters in DML statements
-----------------------------------------
Key: HHH-5775
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5775
Project: Hibernate Core
Issue Type: Improvement
Components: core, query-hql
Reporter: Jason Clawson
We are using filters to support multi-tenency, an approach alluded to in this recent blog post: http://in.relation.to/Bloggers/MultitenancyInHibernate. It works create for HQL selects but doesn't work for Updates / Deletes. Looking through the source code, this seems to have been a conscious choice as some comments indicate. If filters are meant to be used for multitenency, this seems to be the wrong choice. I would like to see session filters affect updates and deletes. This seems very logical because if I run the select: SELECT * FROM User which is affected by a filter and returns 2 users, and then execute DELETE FROM User which deletes all the users in the system--- thats not what I would expect to happen.
I believe this will require modifications to HqlSqlWalker and the ANTLR script sql-gen.g. I am looking into what other modifications are necessary, but I would appreciate it if the Hibernate folks could take a look since they would be most familiar with the code and the decisions behind it.
Thanks!
--
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
12 years, 10 months
[Hibernate-JIRA] Created: (HHH-5299) Multi-Level cascading of unsaved instances with bidirectional associations fails with TransientObjectException
by Carl-Eric Menzel (JIRA)
Multi-Level cascading of unsaved instances with bidirectional associations fails with TransientObjectException
--------------------------------------------------------------------------------------------------------------
Key: HHH-5299
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5299
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2
Environment: Tested with OracleXE and H2DB, Hibernate Core 3.3.2, Hibernate Entity Manager 3.4.0
Reporter: Carl-Eric Menzel
Priority: Critical
Attachments: 0001-fixed-no-cascading-check-to-also-accept-entities-wit.patch, cascadetest.zip
Given the following classes (pseudocode, full source in the attached zipfile):
Top {
@OneToMany(cascade = { CascadeType.ALL }, mappedBy = "top")
List<Middle> middles
}
Middle {
@ManyToOne
Top top
@OneToOne(cascade = { CascadeType.ALL })
@JoinColumn(name = "BOTTOM_ID")
Bottom bottom
}
Bottom {
@OneToOne(mappedBy = "bottom")
Middle middle
}
The following code fails on the second flush with a TransientObjectException:
Top top = new Top();
em.persist(top);
em.flush();
// top is now attached, status MANAGED
Middle middle = new Middle(1l);
middle.setBottom(new Bottom());
top.addMiddle(middle);
Middle middle2 = new Middle(2l);
middle2.setBottom(new Bottom());
top.addMiddle(middle2);
// both middles and bottoms are transient but should be saved by cascade
em.flush(); // boom!
The relevant part of the error is:
org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: test.Bottom.middle -> test.Middle
at org.hibernate.engine.CascadingAction$9.noCascade(CascadingAction.java:376)
at org.hibernate.engine.Cascade.cascade(Cascade.java:163)
The same code works without exception when using EclipseLink instead of Hibernate EntityManager, so I am assuming that the test code is valid.
Some debugging revealed that CascadingAction.PERSIST_ON_FLUSH.noCascade() checks the inverse association from Bottom to Middle. It then calls a private method isInManagedState to verify that this association does not reference an unsaved instance. It does this by checking the entities EntityEntry.getStatus() value, which it expects to be MANAGED or READ_ONLY. At this time, however, the Middle instance is in the middle (no pun intended) of its own cascading save cycle and therefore its status is SAVING. This, to me, seems to be a valid session-attached status, so isInManagedState() should also accept this state.
The attached patch against Hibernate Core 3.3.2 implements just that, and this change makes the above example code work as expected. The Hibernate test suite did not complain, so I am reasonably sure I did not break anything else.
See also the attached cascadetest.zip for a ready-to-use testcase that demonstrates the error with Hibernate Core 3.3.2. Change the dependency in the supplied pom.xml to a patched version of Hibernate Core, and the test will no longer fail.
Carl-Eric Menzel
C1 SetCon GmbH
--
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
12 years, 10 months
[Hibernate-JIRA] Created: (HHH-6824) Hibernate query unexpectedly returns duplicate results
by Matthew Casperson (JIRA)
Hibernate query unexpectedly returns duplicate results
------------------------------------------------------
Key: HHH-6824
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6824
Project: Hibernate Core
Issue Type: Bug
Components: query-hql
Affects Versions: 3.6.8
Environment: JBoss AS7, Seam 2.2.2
Reporter: Matthew Casperson
I have a situation where a query run through Hibernate is returning a single duplicate record, where the same query in SQL does not. The SQL query (formatted for readability) is:
select * from Topic where
(
(
exists (select 1 from TopicToTag where TopicToTag.TopicID = Topic.TopicID and TopicToTag.TagID = 119)
Or exists (select 1 from TopicToTag where TopicToTag.TopicID = Topic.TopicID and TopicToTag.TagID = 133)
Or exists (select 1 from TopicToTag where TopicToTag.TopicID = Topic.TopicID and TopicToTag.TagID = 132)
)
And
(
exists (select 1 from TopicToTag where TopicToTag.TopicID = Topic.TopicID and TopicToTag.TagID = 19)
And not exists (select 1 from TopicToTag where TopicToTag.TopicID = Topic.TopicID and TopicToTag.TagID = 14)
)
)
The Hibernate query is:
select topic from com.redhat.topicindex.entity.Topic as Topic where ((exists (select 1 from TopicToTag topicToTag where topicToTag.topic = topic and topicToTag.tag.tagId = 132) Or exists (select 1 from TopicToTag topicToTag where topicToTag.topic = topic and topicToTag.tag.tagId = 119) Or exists (select 1 from TopicToTag topicToTag where topicToTag.topic = topic and topicToTag.tag.tagId = 133) ) And (exists (select 1 from TopicToTag topicToTag where topicToTag.topic = topic and topicToTag.tag.tagId = 19) And not exists (select 1 from TopicToTag topicToTag where topicToTag.topic = topic and topicToTag.tag.tagId = 14) ))
The SQL query will return 474 records, while the Hibernate will return 475 entities with 1 duplicate.
The details of the tables are:
Table Topic
===========
TopicID, TopicTitle, TopicText, TopicAddedBy, TopicTimeStamp, TopicSVNURL, TopicXML
-----------
TopicID int(11) PK
TopicTitle varchar(512)
TopicText text
TopicAddedBy varchar(512)
TopicTimeStamp timestamp
TopicSVNURL varchar(512)
TopicXML text
Table TopicToTag
================
TopicToTagID, TopicID, TagID
----------------
TopicToTagID int(11) PK
TopicID int(11)
TagID int(11)
Table Tag
=========
TagID, TagName, TagDescription
---------
TagID int(11) PK
TagName varchar(512)
TagDescription text
The code for the entities can be viewed at:
https://sourceforge.net/p/topicindex/code/383/tree/trunk/src/main/com/red...
https://sourceforge.net/p/topicindex/code/383/tree/trunk/src/main/com/red...
https://sourceforge.net/p/topicindex/code/383/tree/trunk/src/main/com/red...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months