-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

View unanswered posts | View active topics


Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]


Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 1 of 1
  [ 5 posts ] 
  Previous topic | Next topic 
Author Message
enduriel
 Post subject: Envers 3.6.1 -ValidityAuditStrategy fails on @ManyToMany Set
PostPosted: Mon Feb 14, 2011 1:46 pm 
Newbie

Joined: Mon Feb 14, 2011 8:42 am
Posts: 3
Hello Hibernate Forum,

I have encountered a strange bug in Envers 3.6.1 that throws an error after adding and removing and readding an entity to a set.

At least I think it's a bug. Please correct me if I made anything wrong in my configuration (or in any other way).

The situation is as follows:

There are two Entities, like the following:

User.java:
Code:
// plus imports

@Entity
@Audited
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    @ManyToMany
    private Set<EMail> eMails = new HashSet<EMail>();

    // plus getters and setters

}



EMail.java:
Code:
// plus imports

@Entity
@Audited
public class EMail {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private String email;

    // plus getters and setters

}


This generates six tables (User, User_AUD, User_EMail, User_EMail_AUD, EMail, EMail_AUD).

Now the following steps recreate the bug:

We create a new User and a new Email.

We add the email to the user, a create entry in the audit table 'user_email_aud' is generated.
We remove the email from the user, a delete entry is generated in the audit table 'user_email_aud and the revend of first entry is updated (so far alright).

Now we add the same email (with the same id) to the user, and a create entry is generated in 'user_email_aud'. But the previous delete entry is not updated.
If we now try to remove the email from the user again, then we get an Exception:

Quote:
18:50:12.068 [main] ERROR org.hibernate.AssertionFailure - an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
java.lang.RuntimeException: Cannot find previous revision for entity User_EMail_AUD and id {REV=DefaultRevisionEntity(id = 5, revisionDate = 14.02.2011 18:50:12), eMails_id=1, User_id=1}
at org.hibernate.envers.strategy.ValidityAuditStrategy.updateLastRevision(ValidityAuditStrategy.java:175) ~[hibernate-envers-3.6.1.Final.jar:3.6.1.Final]
at org.hibernate.envers.strategy.ValidityAuditStrategy.performCollectionChange(ValidityAuditStrategy.java:96) ~[hibernate-envers-3.6.1.Final.jar:3.6.1.Final]
at org.hibernate.envers.synchronization.work.PersistentCollectionChangeWorkUnit.perform(PersistentCollectionChangeWorkUnit.java:88) ~[hibernate-envers-3.6.1.Final.jar:3.6.1.Final]
at org.hibernate.envers.synchronization.AuditProcess.executeInSession(AuditProcess.java:114) ~[hibernate-envers-3.6.1.Final.jar:3.6.1.Final]
at org.hibernate.envers.synchronization.AuditProcess.doBeforeTransactionCompletion(AuditProcess.java:152) ~[hibernate-envers-3.6.1.Final.jar:3.6.1.Final]
at org.hibernate.engine.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:543) ~[hibernate-core-3.6.1.Final.jar:3.6.1.Final]
at org.hibernate.engine.ActionQueue.beforeTransactionCompletion(ActionQueue.java:216) [hibernate-core-3.6.1.Final.jar:3.6.1.Final]
at org.hibernate.impl.SessionImpl.beforeTransactionCompletion(SessionImpl.java:571) [hibernate-core-3.6.1.Final.jar:3.6.1.Final]
at org.hibernate.jdbc.JDBCContext.beforeTransactionCompletion(JDBCContext.java:250) [hibernate-core-3.6.1.Final.jar:3.6.1.Final]
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:138) [hibernate-core-3.6.1.Final.jar:3.6.1.Final]
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:76) [hibernate-entitymanager-3.6.1.Final.jar:3.6.1.Final]
at de.cosmocode.enverstest.UserTest.multiCreate(UserTest.java:120) [test-classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.6.0_22]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) ~[na:1.6.0_22]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_22]
at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_22]
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit-4.7.jar:na]
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit-4.7.jar:na]
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit-4.7.jar:na]
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit-4.7.jar:na]
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) [junit-4.7.jar:na]
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) [junit-4.7.jar:na]
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) [junit-4.7.jar:na]
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [junit-4.7.jar:na]
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) [junit-4.7.jar:na]
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) [junit-4.7.jar:na]
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) [junit-4.7.jar:na]
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) [junit-4.7.jar:na]
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) [junit-4.7.jar:na]
at org.junit.runners.ParentRunner.run(ParentRunner.java:236) [junit-4.7.jar:na]
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) [surefire-junit4-2.5.jar:2.5]
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115) [surefire-api-2.5.jar:2.5]
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102) [surefire-api-2.5.jar:2.5]
at org.apache.maven.surefire.Surefire.run(Surefire.java:180) [surefire-api-2.5.jar:2.5]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.6.0_22]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) ~[na:1.6.0_22]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_22]
at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_22]
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) [surefire-booter-2.5.jar:2.5]
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) [surefire-booter-2.5.jar:2.5]



A test case, where it occurs, can be fetched here (checkout with git, needs maven):
https://github.com/olilo/envers-validity-strategy-bug

The error can be seen with "mvn clean test".

The test file is under src/test/java/de/cosmocode/enverstest/UserTest.java.

If I made any mistake in my configuration then I would be happy if you could point the mistake out, so I can fix it.
Otherwise I hope that the information I provided helps so far.
Top
 Profile  
 
enduriel
 Post subject: Re: Envers 3.6.1 -ValidityAuditStrategy fails on @ManyToMany Set
PostPosted: Fri Feb 25, 2011 6:47 am 
Newbie

Joined: Mon Feb 14, 2011 8:42 am
Posts: 3
Well, not to put any pressure here, but does anyone know something about this? Is this an issue with my configuration or with hibernate?

I would appreciate any answers.
Top
 Profile  
 
benpoole
 Post subject: Re: Envers 3.6.1 -ValidityAuditStrategy fails on @ManyToMany Set
PostPosted: Mon Jun 06, 2011 8:00 am 
Newbie

Joined: Mon Jun 06, 2011 7:52 am
Posts: 2
Hi,

We are experiencing the same issue as this, detailed at: http://community.jboss.org/thread/164773?tstart=0

Did you manage find out why the REVEND column was not being populated when using the ValidityAuditStrategy?

Thanks
Top
 Profile  
 
enduriel
 Post subject: Re: Envers 3.6.1 -ValidityAuditStrategy fails on @ManyToMany Set
PostPosted: Mon Jun 06, 2011 10:24 am 
Newbie

Joined: Mon Feb 14, 2011 8:42 am
Posts: 3
Hi benpoole,

after some research I have found out that this is a bug in envers that will be fixed in version 3.6.5.

In the meantime I have switched back to the normal strategy. This is not the ideal solution, because the ValidityAuditStrategy really gives some major speed improvements, but this will nevertheless work until they fix it, I think.

kind regards
enduriel aka Oli
Top
 Profile  
 
benpoole
 Post subject: Re: Envers 3.6.1 -ValidityAuditStrategy fails on @ManyToMany Set
PostPosted: Tue Jun 07, 2011 12:06 pm 
Newbie

Joined: Mon Jun 06, 2011 7:52 am
Posts: 2
Hi Oli,

Thanks for the quick response.

Unfortunately we have such a large existing data set that reverting to the DefaultAuditStrategy is not an option (some many ManyToMany queries take over 10 seconds!).
I should warn you that as your data set grows you may also experience this issue with ManyToMany relationships due to the expensive sub-queries the DefaultAuditStrategy performs.

We have written a workaround to solve the issue.
The workaround involves overriding the collection update event listener:
Code:
<entry key="hibernate.ejb.event.pre-collection-remove" value="your.overriden.RevisioningAuditEventListener" />

For each ManyToMany relationship we run a variation of the following query:

Code:
UPDATE assoc_location_facility_AUD SET REVEND = (
   SELECT REV FROM (
      SELECT REV, location_id
      FROM assoc_location_facility_AUD
      WHERE location_id = 11
   ) x
   WHERE x.location_id = assoc_location_facility_AUD.location_id
   AND x.REV > assoc_location_facility_AUD.REV
   ORDER BY REV ASC
   LIMIT 1
)
WHERE location_id = 11 AND REVEND IS null


This ensures the REVEND column is populated following the collection update event, tested on 7 ManyToMany relationships so far with 100% a success rate.

The workaround is not ideal but will be sufficient until 3.6.5 is released.

Regards

Ben
Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 1 of 1
  [ 5 posts ] 

Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.