This is really becoming a PITA for bulk inserts, since it causes Envers to needlessly run tons of SELECT, INSERT and UPDATE statements against the database. In the hope that someone can support me in solving this issue, let me illustrate what is getting in between me and performance using a very short example:
Imagine we have two entity classes Supplier and Product, each mapped to its own database table. There is a bidirectional 1:n relationship between them, so that a supplier can offer various products but each product is delivered by exactly one supplier. As a consequence, Product is the owning side and Supplier is the non-owning side of the relationship (i.e., uses the mappedBy annotation property). Since the domain model is much more complex in reality and I have to import lots of data into the database, I do it in batches - in the example first all suppliers and afterwards all products.
Now here comes the problem: Whenever a new product is added to the database, its relationship to the previously imported supplier is established, which causes the non-owning side of the relationship to be updated (i.e., the Supplier instance gets changed logically but not physically, because the relationship is stored as part of the product database table). Therefore in principle no change to the supplier database table is required, but Envers generates a new revision for the supplier, which is useless for me. As a consequence, when importing products into the database, Envers executes a lot of SELECT, UPDATE and INSERT operations on the supplier database table thereby tremendously slowing down the batch import of products.
In reality there are a couple of other bidirectional relationships that have Supplier at the non-owning side, which causes the SELECT statements to degrade in performance more and more. How can I change this? Even if this will not make it into Envers itself, can you suggest a way of altering that behavior, e.g., by using a dedicated Envers listener?
Thanks and best regards,
Michael
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
This is really becoming a PITA for bulk inserts, since it causes Envers to needlessly run tons of SELECT, INSERT and UPDATE statements against the database. In the hope that someone can support me in solving this issue, let me illustrate what is getting in between me and performance using a very short example:
Imagine we have two entity classes Supplier and Product, each mapped to its own database table. There is a bidirectional 1:n relationship between them, so that a supplier can offer various products but each product is delivered by exactly one supplier. As a consequence, Product is the owning side and Supplier is the non-owning side of the relationship (i.e., uses the mappedBy annotation property). Since the domain model is much more complex in reality and I have to import lots of data into the database, I do it in batches - in the example first all suppliers and afterwards all products.
Now here comes the problem: Whenever a new product is added to the database, its relationship to the previously imported supplier is established, which causes the non-owning side of the relationship to be updated (i.e., the Supplier instance gets changed logically but not physically, because the relationship is stored as part of the product database table). Therefore in principle no change to the supplier database table is required, but Envers generates a new revision for the supplier, which is useless for me. As a consequence, when importing products into the database, Envers executes a lot of SELECT, UPDATE and INSERT operations on the supplier database table thereby tremendously slowing down the batch import of products.
In reality there are a couple of other bidirectional relationships that have Supplier at the non-owning side, which causes the SELECT statements to degrade in performance more and more. How can I change this? Even if this will not make it into Envers itself, can you suggest a way of altering that behavior, e.g., by using a dedicated Envers listener?
Thanks and best regards,
Michael