[Hibernate-JIRA] Created: (HHH-4555) Support use of Envers with Auto-commit mode.
by Kevin Schmidt (JIRA)
Support use of Envers with Auto-commit mode.
--------------------------------------------
Key: HHH-4555
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4555
Project: Hibernate Core
Issue Type: New Feature
Components: envers
Affects Versions: 3.5.0-Beta-2
Environment: Hibernate 3.5.0-Beta-2
Reporter: Kevin Schmidt
Currently Envers is designed so that it synchronizes with the currently running transaction in order to know when to commit the inserts into the Audit Tables. This is an effective strategy for ensuring that the audit information is only saved to the database if the Transactional Unit of Work which caused the audit data to be created is committed.
This design creates a limitation on Envers such that it cannot persist audit information unless there is an active transaction. This effectively disables auditing for anyone modifying data using Hibernate outside of a Hibernate Transaction. Specifically, if you are using Autocommit = True and manually flushing the Hibernate Session then you cannot have any of your data audited using Envers.
I am not that well versed with the design of Envers but was hoping this situation could be detected and avoided. Maybe the audit information could be synchronized on the flush event rather than when a transaction is committed to the database.
--
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, 11 months
[Hibernate-JIRA] Created: (HHH-3383) QueryKey is storing references to entities instead of identifiers
by Manuel Dominguez Sarmiento (JIRA)
QueryKey is storing references to entities instead of identifiers
-----------------------------------------------------------------
Key: HHH-3383
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3383
Project: Hibernate3
Issue Type: Improvement
Components: caching (L2)
Affects Versions: 3.3.0.CR1
Environment: ehcache 1.5.0b2
Reporter: Manuel Dominguez Sarmiento
Context: query caching
Hibernate is storing full entity references when building QueryKeys and the query has restrictions which reference entities. This happens either with Criteria or HQL queries.
Although this is not incorrect, when the referenced entities reference in turn "heavy" object graphs, this causes a very significant memory usage increase, since references to detached entities will remain in the cache. This is even more evident when using disk persistence with ehcache, since the full object graphs are serialized to disk.
This could be easily improved (correct me if I'm wrong) by storing ONLY entity identifiers in the QueryKey instead of full entities, since all the query really needs is the identifier property. The memory usage would decrease dramatically.
So far the workaround we've found is explicitly using restrictions that reference identifiers instead of properties in HQL queries, however this is not particularly elegant, and still leaves open the issue with Criteria queries. The same cannot be done without criteria.createCriteria() which generates an unnecessary join in most cases.
--
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, 11 months
[Hibernate-JIRA] Created: (HHH-2763) (lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()
by S.Schnabl (JIRA)
(lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()
--------------------------------------------------------------------------------------------------------
Key: HHH-2763
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5, 3.2.4.sp1
Environment: Windows-XP, Jboss 4.2.1GA, Hibernate 3.2.4SP1, EJB3
Reporter: S.Schnabl
Priority: Critical
Attachments: Testcase.zip
For more details see the attached testcase. I'm sorry, but in the short of time i only got a testcase for jboss-server 4.2. Please deploy the server.ear from /release-directory and then call the /src/client/TestCaseClient.java.
[Summarized]
It seems, that touching a lazy (Persistent-)Collection of at least a m:n relation inside a Hibernate event-listener always raises this error:
org.hibernate.AssertionFailure: collection [n-side] was not processed by flush()
[Explanation]
I have two entities A. and B. Both having a m:n relation between each other. Furthermore there is an PostUpdateListener, which iterates onUpdate of entitiy through all properties of updated entity.
[Testcase]
Both entities are linked with eachother (m:n). If i now do a simple update of a property of entity A --> MyPostUpdateListener will be called, which iterates through every property of the updated entity. In case of this property was a collection (= lazy PersistentCollection of m:n relation), hibernate initializes the collection for further work. I can now run through all objects of the collection, but after all work is done in listener, I get the following exception from postFlush:
Caused by: org.hibernate.AssertionFailure: collection [com.qualitype.testcase.server.ejb.entity.EntityB.entitiesOfA] was not processed by flush()
at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:205)
at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:333)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515)
... 29 more
Attention: EntityB.entitiesOfA is the other-side collection of the m:n relation of the updated EntityA.
We are using hibernate-event listener system for auditing-purposes, so you should understand that touching every (element in the) collection is necessary for audit-purposes.
Seems for me like a serious bug. Need this fixed asap ...
--
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, 12 months
[Hibernate-JIRA] Created: (HHH-2511) generated="insert/always" ignored for property in composite-element?
by James Garrison (JIRA)
generated="insert/always" ignored for property in composite-element?
--------------------------------------------------------------------
Key: HHH-2511
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2511
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Environment: Hibernate 3.2.2, Windows XP SP2, Oracle 9i
Reporter: James Garrison
Priority: Minor
I have a composite-element (in an idbag) that has a db-generated timestamp
property. I have defined the property with update="false" insert="false" generated="insert",
but Hibernate is trying to insert a null value when saving a transient object.
See below, the "createTs" property (column=CREATE_TS) in the "comments"
composite-element.
DDL:
create table CR_COMMENT
(
COMMENT_ID integer not null,
REQ_ID integer not null,
CREATE_TS timestamp default sysdate not null,
SECTION_ID char(1) not null,
USER_ID varchar2(20) not null,
TEXT varchar2(4000) not null,
primary key(COMMENT_ID),
foreign key(REQ_ID) references CR_REQUEST (REQ_ID) on delete cascade
);
Mapping:
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="com.wholefoods.ittoolkit.ws.ccf">
<class name="Request" table="CR_REQUEST">
<id name="reqId" column="REQ_ID" type="long">
<generator class="sequence">
<param name="sequence">CR_REQUEST_ID</param>
</generator>
</id>
[snip]
<idbag name="comments" table="CR_COMMENT">
<collection-id type="long" column="COMMENT_ID">
<generator class="sequence">
<param name="sequence">CR_COMMENT_ID</param>
</generator>
</collection-id>
<key column="REQ_ID" />
<composite-element class="Comment">
<property name="createTs" column="CREATE_TS"
type="calendar"
access="field"
update="false"
insert="false"
generated="insert" />
<property name="sectionId" column="SECTION_ID" />
<property name="userId" column="USER_ID" />
<property name="text" column="TEXT"/>
</composite-element>
</idbag>
</class>
</hibernate-mapping>
Log Output:
Hibernate:
/* insert collection
row com.wholefoods.ittoolkit.ws.ccf.Request.comments */ insert
into
ITTOOLKIT.CR_COMMENT
(REQ_ID, COMMENT_ID, CREATE_TS, SECTION_ID, USER_ID, TEXT)
values
(?, ?, ?, ?, ?, ?)
10:15:01,659 DEBUG org.hibernate.jdbc.AbstractBatcher:476 - preparing statement
10:15:01,675 DEBUG org.hibernate.type.LongType:133 - binding '47' to parameter: 1
10:15:01,675 DEBUG org.hibernate.type.LongType:133 - binding '7' to parameter: 2
10:15:01,675 DEBUG org.hibernate.type.CalendarType:126 - binding null to parameter: 3
10:15:01,675 DEBUG org.hibernate.type.StringType:133 - binding 'A' to parameter: 4
10:15:01,690 DEBUG org.hibernate.type.StringType:133 - binding 'garrisoj' to parameter: 5
10:15:01,690 DEBUG org.hibernate.type.StringType:133 - binding 'This is a test comment' to parameter: 6
10:15:01,690 DEBUG org.hibernate.persister.collection.AbstractCollectionPersister:1172 - done inserting collection: 1 rows inserted
10:15:01,690 DEBUG org.hibernate.jdbc.AbstractBatcher:44 - Executing batch size: 1
10:15:01,737 DEBUG org.hibernate.jdbc.AbstractBatcher:366 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
10:15:01,737 DEBUG org.hibernate.jdbc.AbstractBatcher:525 - closing statement
10:15:01,768 DEBUG org.hibernate.util.JDBCExceptionReporter:69 - Could not execute JDBC batch update
[/* insert collection row com.wholefoods.ittoolkit.ws.ccf.Request.comments */
insert into ITTOOLKIT.CR_COMMENT (REQ_ID, COMMENT_ID, CREATE_TS, SECTION_ID, USER_ID, TEXT)
values (?, ?, ?, ?, ?, ?)]
java.sql.BatchUpdateException: ORA-01400: cannot insert NULL into ("ITTOOLKIT"."CR_COMMENT"."CREATE_TS")
--
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, 12 months
[Hibernate-JIRA] Created: (HHH-2455) "Could not close a JDBC result set" output very often
by Dirk Feufel (JIRA)
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
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, 12 months
[Hibernate-JIRA] Created: (HCANN-9) Unable to reference JPA entity beans in a different package
by Krashan Brahmanjara (JIRA)
Unable to reference JPA entity beans in a different package
-----------------------------------------------------------
Key: HCANN-9
URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-9
Project: Hibernate Commons Annotations
Issue Type: Bug
Environment: Hibernate Annotations 3.4.0.GA in Jboss 5.1.0.GA
Reporter: Krashan Brahmanjara
Problem described in
https://forum.hibernate.org/viewtopic.php?f=1&t=998404
Example
Two classes test.jpa.db1.Card ant test.jpa.db2.Cards are in different packages in the same jar and @ManyToOne fails if deployed on Jboss server
... but it work if these clases are together in the same package.
... it not fails on Weblogic with OpenJpa
Stack trace
09:53:37,609 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=test-services-ear
.ear/test-services-ejb-3.0.alfa-SNAPSHOT.jar#test-services-jpa state=Create
org.hibernate.AnnotationException: @OneToOne or @ManyToOne on test.jpa.db1.Card.podm references an unknown ent
ity: test.jpa.db2.Cards
at org.hibernate.cfg.ToOneFkSecondPass.doSecondPass(ToOneFkSecondPass.java:81)
at org.hibernate.cfg.AnnotationConfiguration.processEndOfQueue(AnnotationConfiguration.java:456)
at org.hibernate.cfg.AnnotationConfiguration.processFkSecondPassInOrder(AnnotationConfiguration.java:438)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:309)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
at org.jbtest.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
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.jbtest.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jbtest.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
Tested workarounds, both doesn't work:
- adding an orm.xml file with entries like:
<entity>test.jpa.db1.Card</entity>
<entity>test.jpa.db2.Cards</entity>
- adding an hibernate extensions to class definition like:
@Entity
@org.hibernate.annotations.Entity
@Table(name = "card")
public class Card implements Serializable {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[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
13 years