5 a.m.
Materializing proxy fails non-deterministic with "[-4000] (at 10): Unknown result
table"
----------------------------------------------------------------------------------------
Key: HHH-3599
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3599
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Environment: MaxDB 7.6.05.09, Linux, JDBC
Reporter: Dirk Lachowski
We have a quite simple domain object:
@Entity
@Table(name = "cc_user_assignment")
@org.hibernate.annotations.Proxy(lazy = true)
public class CostCenterUserAssignment {
private Long id;
private Contact contact;
private Set<CostCenter> costCenter = new HashSet<CostCenter>();
private CostCenter defaultCostCenter;
@ManyToMany
@JoinTable(name = "j_cc_user2user", joinColumns = { @JoinColumn(name =
"user_assignment_id") }, inverseJoinColumns = @JoinColumn(name =
"cost_center_id"))
public Set<CostCenter> getCostCenter() {
return costCenter;
}
public void removeCostCenter(CostCenter ccRemove) {
costCenter.remove(ccRemove);
}
}
Most of the time the call to "removeCostCenter()" succeeds, but now we have a
non-reproducible situation where the call to costCenter.remove(ccRemove) fails. It seems
to be data-dependend as it occurs in one of our productive systems. There it is
reproducible for one set of data. First we thought it is dependent on the data-size but
we are not able to reproduce it by simply creating another dataset of the same size.
The select created for the proxy-materializing is:
select
costcenter0_.user_assignment_id as user1_10_,
costcenter0_.cost_center_id as cost2_10_,
costcenter1_.id as id169_0_,
costcenter1_.accountNumber as accountN2_169_0_,
costcenter1_.balance as balance169_0_,
costcenter1_.balance_currency as balance4_169_0_,
costcenter1_.budget as budget169_0_,
costcenter1_.budget_currency as budget6_169_0_,
costcenter1_.budgetExcessAllowed as budgetEx7_169_0_,
costcenter1_.bdg_extra as bdg8_169_0_,
costcenter1_.bdg_extra_currency as bdg9_169_0_,
costcenter1_.budgetPeriod as budgetP10_169_0_,
costcenter1_.customer_id as customer13_169_0_,
costcenter1_.manager_id as manager14_169_0_,
costcenter1_.name as name169_0_,
costcenter1_.transferBudget as transfe12_169_0_,
customer2_.id as id167_1_,
customer2_.accountId as accountId167_1_,
customer2_.addr_id as addr16_167_1_,
customer2_.attribute01 as attribute3_167_1_,
customer2_.attribute02 as attribute4_167_1_,
customer2_.attribute03 as attribute5_167_1_,
customer2_.attribute04 as attribute6_167_1_,
customer2_.attribute05 as attribute7_167_1_,
customer2_.attribute06 as attribute8_167_1_,
customer2_.attribute07 as attribute9_167_1_,
customer2_.attribute08 as attribute10_167_1_,
customer2_.attribute09 as attribute11_167_1_,
customer2_.attribute10 as attribute12_167_1_,
customer2_.delivery_lock_id as delivery17_167_1_,
customer2_.externalAccountId1 as externa13_167_1_,
customer2_.externalAccountId2 as externa14_167_1_,
customer2_.owner_id as owner18_167_1_,
customer2_.pricelist_id as pricelist19_167_1_,
customer2_.pricingSchemaName as pricing15_167_1_,
address3_.id as id165_2_, address3_.city as city165_2_,
address3_.country_id as country16_165_2_,
address3_.fax as fax165_2_,
address3_.fon as fon165_2_,
address3_.houseNumber as houseNum5_165_2_,
address3_.mail as mail165_2_,
address3_.name1 as name7_165_2_,
address3_.name2 as name8_165_2_,
address3_.name3 as name9_165_2_,
address3_.name4 as name10_165_2_,
address3_.postbox as postbox165_2_,
address3_.postcode as postcode165_2_,
address3_.postcodeCompany as postcod13_165_2_,
address3_.postcodePostbox as postcod14_165_2_,
address3_.street as street165_2_,
address3_.title_id as title17_165_2_,
country4_.id as id159_3_,
country4_.isoCode as isoCode159_3_,
country4_.name as name159_3_,
title5_.id as id163_4_,
title5_.isOrganization as isOrgani2_163_4_,
title5_.name as name163_4_,
deliverylo6_.id as id191_5_,
deliverylo6_.autoDeliveryLock as autoDeli2_191_5_,
deliverylo6_.description as descript3_191_5_,
deliverylo6_.messageLock as messageL4_191_5_,
deliverylo6_.name as name191_5_,
deliverylo6_.orderLock as orderLock191_5_,
deliverylo6_.reservationLock as reservat7_191_5_,
pricelistt7_.id as id175_6_,
pricelistt7_.description as descript2_175_6_,
pricelistt7_.name as name175_6_,
contact8_.id as id166_7_,
contact8_.customer_id as customer12_166_7_,
contact8_.firstName as firstName166_7_,
contact8_.ignoreAssortment as ignoreAs3_166_7_,
contact8_.lastName as lastName166_7_,
contact8_.officeFax as officeFax166_7_,
contact8_.officeMail as officeMail166_7_,
contact8_.officeMobile as officeMo7_166_7_,
contact8_.officePhone as officePh8_166_7_,
contact8_.role as role166_7_,
contact8_.title_id as title13_166_7_,
contact8_.webPassword as webPass10_166_7_,
contact8_.webUserName as webUser11_166_7_,
customer9_.id as id167_8_,
customer9_.accountId as accountId167_8_,
customer9_.addr_id as addr16_167_8_,
customer9_.attribute01 as attribute3_167_8_,
customer9_.attribute02 as attribute4_167_8_,
customer9_.attribute03 as attribute5_167_8_,
customer9_.attribute04 as attribute6_167_8_,
customer9_.attribute05 as attribute7_167_8_,
customer9_.attribute06 as attribute8_167_8_,
customer9_.attribute07 as attribute9_167_8_,
customer9_.attribute08 as attribute10_167_8_,
customer9_.attribute09 as attribute11_167_8_,
customer9_.attribute10 as attribute12_167_8_,
customer9_.delivery_lock_id as delivery17_167_8_,
customer9_.externalAccountId1 as externa13_167_8_,
customer9_.externalAccountId2 as externa14_167_8_,
customer9_.owner_id as owner18_167_8_,
customer9_.pricelist_id as pricelist19_167_8_,
customer9_.pricingSchemaName as pricing15_167_8_,
title10_.id as id163_9_,
title10_.isOrganization as isOrgani2_163_9_,
title10_.name as name163_9_
from
j_cc_user2user costcenter0_,
cost_center costcenter1_,
KNA1 customer2_,
ADDR address3_,
C005 country4_,
CSAD3 title5_,
delivery_lock deliverylo6_,
sd_pr_prltype pricelistt7_,
KNVK contact8_,
KNA1 customer9_,
CSAD3 title10_
where
costcenter0_.cost_center_id=costcenter1_.id(+)
and costcenter1_.customer_id=customer2_.id(+)
and customer2_.addr_id=address3_.id(+)
and address3_.country_id=country4_.id(+)
and address3_.title_id=title5_.id(+)
and customer2_.delivery_lock_id=deliverylo6_.id(+)
and customer2_.pricelist_id=pricelistt7_.id(+)
and costcenter1_.manager_id=contact8_.id(+)
and contact8_.customer_id=customer9_.id(+)
and contact8_.title_id=title10_.id(+)
and costcenter0_.user_assignment_id=?
The same query can be successfully submitted using database studio.
Maybe it's related to this:
http://osdir.com/ml/db.maxdb/2004-10/msg00199.html
A full stack trace is available here:
http://jira.lacho.net/jira/browse/ES-579
--
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