Hi!

Ich verwende die Criteria-API für eine Abfrage, und sie dauert minutenlang, obwohl eigentlich nur 147 Datensätze vom Typ Durchfuehrung (Subklasse von DfVorlageBasis) abgefragt werden. Das Problem ist vermutlich, dass sämtliche Collections geladen werden, obwohl sie eigentlich als lazy konfiguriert sind.
Liegt trotzdem ein Konfigurationsfehler vor?

Hibernate version:
3.1rc3

Mapping documents:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping
package="de.fhzw.portal.umfragesystem.model.domainmodel.umfrage">

<class name="DfVorlageBasis" table="DF_VORLAGE_BASIS" lazy="true"
dynamic-insert="true" dynamic-update="true">

<id name="id" unsaved-value="0">
<generator class="increment" />
</id>

<property name="bezeichnung" not-null="true" />
<property name="beschreibung" />
<property name="begrText" column="BEGR_TEXT" />
<property name="begrTextAnzeige" column="BEGR_TEXT_ANZEIGE"
not-null="true" />
<property name="abschText" column="ABSCH_TEXT" />
<property name="abschTextAnzeige" column="ABSCH_TEXT_ANZEIGE"
not-null="true" />
<property name="teilnSicherheit" column="TEILN_SICHERHEIT"
not-null="true" />
<property name="auswSicherheitSuper" column="AUSW_SICHERHEIT_SUPER"
not-null="true" />
<property name="auswSicherheitSub" column="AUSW_SICHERHEIT_SUB"
not-null="true" />
<property name="kennwort" />

<property name="umfrBeginn" type="timestamp" column="UMFR_BEGINN"
not-null="true" />
<property name="umfrEnde" type="timestamp" column="UMFR_ENDE"
not-null="true" />
<property name="ergPubBeginnOpt" column="ERG_PUB_BEGINN_OPT"
not-null="true" />
<property name="ergPubBeginn" type="timestamp" column="ERG_PUB_BEGINN" />
<property name="ergPubEnde" type="timestamp" column="ERG_PUB_ENDE" />
<property name="ergPubAnzahl" column="ERG_PUB_ANZAHL" />
<property name="studentenOpt" column="STUDENTEN_OPT" not-null="true" />
<property name="semester" not-null="true" />
<property name="stgang" not-null="true" />
<property name="fach" not-null="true" />
<property name="gruppe" />
<property name="dozent" not-null="true" />
<property name="fachsem" not-null="true" />
<property name="mitarbeiterOpt" column="MITARBEITER_OPT" not-null="true" />
<property name="fachbereichStud" column="FACHBEREICH_STUD"
not-null="true" />
<property name="fachbereichMit" column="FACHBEREICH_MIT" not-null="true" />
<property name="bereich" not-null="true" />

<!-- Die folgende Formula zaehlt die Fragen einer Durchfuehrung/Vorlage;
sie zaehlt nicht die Fragen von zusammengesetzten Fragen mit,
da Fragen von zusammengesetzten Fragen momentan nur die
zusammengesetzte Frage referenzieren, und nicht die Umfrage.
-->
<property name="anzahlFragen"
formula="(select count(f.id) from Frage f, DF_Vorlage_Basis dvb where
id = dvb.id and dvb.umfrage = f.frage_umfrage)" />

<many-to-one name="umfrage" class="Umfrage" not-null="true" lazy="false"
cascade="save-update" />

<set name="auswertungsberechtigte" lazy="true" inverse="true"
cascade="all-delete-orphan">
<key column="DF_VORLAGE_BASIS"/>
<one-to-many class="Auswertungsberechtigt" />
</set>


<joined-subclass name="Durchfuehrung" lazy="true">
<key column="ID" />
<property name="freigegeben" not-null="true" />
<property name="erneuteDf" column="ERNEUTE_DF" not-null="true" />
<property name="generiert" not-null="true" />
<property name="anzahlRegTeilnehmer" column="ANZAHL_REG_TEILNEHMER"
not-null="true" />
<set name="antwortsaetze" lazy="true" inverse="true" batch-size="16"
cascade="all-delete-orphan">
<key column="DURCHFUEHRUNG" />
<one-to-many class="Antwortsatz" />
</set>
<set name="bereitsabgestimmte" lazy="true" inverse="true"
cascade="all-delete-orphan">
<key column="DURCHFUEHRUNG" />
<one-to-many class="Bereitsabgestimmt" />
</set>
<set name="tanbloecke" lazy="true" inverse="true"
cascade="all-delete-orphan">
<key column="DURCHFUEHRUNG"/>
<one-to-many class="Tanblock" />
</set>
</joined-subclass>

<joined-subclass name="Vorlage" lazy="true">
<key column="ID" />
<property name="gemeinsam" not-null="true" />
</joined-subclass>

</class>
</hibernate-mapping>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="de.fhzw.portal.umfragesystem.model.domainmodel.umfrage">
<class name="Umfrage" lazy="true" dynamic-insert="true" dynamic-update="true">

<id name="id" unsaved-value="0">
<generator class="increment" />
</id>

<property name="umfrTyp" column="UMFR_TYP" not-null="true" />
<property name="fragenAufteilung" column="FRAGEN_AUFTEILUNG"
not-null="true" />
<property name="bearbZeit" column="BEARB_ZEIT" />
<property name="fragebogenLayout" column="FRAGEBOGEN_LAYOUT"
not-null="true" />
<property name="layoutFile" column="FRAGEBOGEN_LAYOUT_FILE" />
<property name="autor" not-null="true" />
<property name="autorName" column="AUTOR_NAME" />
<property name="maxSeitenzahl" column="MAX_SEITENZAHL" not-null="true" />

<set name="fragen" lazy="true" inverse="true" cascade="all-delete-orphan">
<key column="FRAGE_UMFRAGE" />
<one-to-many class="Frage" />
</set>

</class>
</hibernate-mapping>


Code between sessionFactory.openSession() and session.close():
Ich verwendte Container Managed Transactions (JBoss). Der folgende Methodenaufruf mit der DB-Abfrage wird von einer Stateless Session Bean ausgeführt. Die Abfrage dauert minutenlang (9+ Minuten vergehen zwischen Methodeneintritt und Methodenaustritt, obwohl eigentlich nur 147 Datensätze gefunden werden).

public List findDfByAutorRoleUmfrTypUmfrZust(Integer uId,
boolean forUmfrSuperManager, Character umfrTyp, Character umfrZust)
throws InfrastructureException {
DurchfuehrungDAO.log.info("entering findDfByAutorRoleUmfrTypUmfrZust()");
DurchfuehrungDAO.log.debug("Params: uId=" + uId + ", umfrTyp=" + umfrTyp +
", umfrZust=" + umfrZust);

if (uId == null || umfrTyp == null || umfrZust == null) {
DurchfuehrungDAO.log.error("Null Parameter!");
throw new IllegalArgumentException("Null Parameter!");
}

Session session = HibernateUtil.getUmfrageSession();
Criteria criteria = session.createCriteria(Durchfuehrung.class);
List list = null;

switch (umfrZust.charValue()) {
case UmfrageConstants.NICHT_FREI_CHR:
criteria = criteria.add(Property.forName("freigegeben").eq(
Boolean.FALSE));
break;
case UmfrageConstants.FREI_CHR:
criteria = criteria.add(Property.forName("freigegeben").eq(
Boolean.TRUE));
break;
case UmfrageConstants.NICHT_BEG_CHR:
criteria = criteria.add(Property.forName("umfrBeginn").gt(new Date()));
break;
case UmfrageConstants.BEG_CHR:
criteria = criteria.add(Property.forName("umfrBeginn").lt(new Date()));
break;
case UmfrageConstants.NICHT_BEENDET_CHR:
criteria = criteria.add(Property.forName("umfrEnde").gt(new Date()));
break;
case UmfrageConstants.BEENDET_CHR:
criteria = criteria.add(Property.forName("umfrEnde").lt(new Date()));
break;
case UmfrageConstants.OHNE_ERG_CHR:
criteria = criteria.add(Restrictions.sizeEq("antwortsaetze", 0));
break;
case UmfrageConstants.MIT_ERG_CHR:
criteria = criteria.add(Restrictions.sizeGt("antwortsaetze", 0));
break;
default:
DurchfuehrungDAO.log.debug("Umfragezustand not supported: " + umfrZust);
throw new IllegalArgumentException("umfrZust nicht unterstuetzt!");
}

criteria = criteria.createCriteria("umfrage");

if (forUmfrSuperManager) {
criteria = criteria.add(Property.forName("autor").ne(uId)); // nicht vom Autor
} else {
criteria = criteria.add(Property.forName("autor").eq(uId)); // vom Autor
}

criteria = criteria.add(Property.forName("umfrTyp").eq(umfrTyp));

try {

list = criteria.list();

} catch(HibernateException he) {
DurchfuehrungDAO.log.error("HibernateException while trying to query " +
"Durchfuehrung and Umfrage!", he);
throw new InfrastructureException(he);
}
DurchfuehrungDAO.log.debug("Durchfuehrungen = " + list);
DurchfuehrungDAO.log.info("leaving findDfByAutorRoleUmfrTypUmfrZust()");
return list;
}


Full stack trace of any exception that occurs:
Keine Exception.

Name and version of the database you are using:
MaxDB 7.5

The generated SQL (show_sql=true):
Siehe nächster Punkt.

Debug level Hibernate log excerpt:

Der Log-Datei (knapp 200 MB für den Methodenaufruf, Hibernate Debug Level) lässt sich entnehmen, dass Hibernate komischerweise auch Collections lädt, die eigentlich mit lazy="true" konfiguriert sind, z. B.:

loading collection: [de.fhzw.portal.umfragesystem.model.domainmodel.umfrage.Frage.antworten#435]
2006-01-24 22:48:47,640 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
2006-01-24 22:48:47,640 DEBUG [org.hibernate.jdbc.ConnectionManager] opening JDBC connection
2006-01-24 22:48:47,640 DEBUG [org.hibernate.SQL] select antworten0_.FRAGE_ANTWORT as FRAGE4_3_, antworten0_.id as id3_, antworten0_.id as id0_2_, antworten0_.typ as typ0_2_, antworten0_.anmerkungen as anmerkun3_0_2_, antworten0_.FRAGE_ANTWORT as FRAGE4_0_2_, antworten0_.ANTWORTSATZ_ANTWORTEN as ANTWORTS5_0_2_, antworten0_.ZUSAMMENGESANTWORT_ANTWORTEN as ZUSAMMEN6_0_2_, decode(antworten0_.id, antworten0_1_.ID, 1, antworten0_2_.ID, 2, antworten0_3_.ID, 3, antworten0_4_.ID, 4, antworten0_5_.ID, 5, 0) as clazz_2_, textantwor1_.id as id25_0_, textantwor1_.text as text25_0_, textantwor1_.FREIEANTWORT_TEXT as FREIEANT3_25_0_, auswahlant2_.id as id7_1_, auswahlant2_.auswahl as auswahl7_1_, auswahlant2_.textantwort as textantw3_7_1_, auswahlant2_.EINFACHAUSWANTW_AUSWAHL as EINFACHA4_7_1_, auswahlant2_.MEHRFACHAUSWANTW_AUSWAHL as MEHRFACH5_7_1_, auswahlant2_.MTRXTEILANTW_AUSWAHL as MTRXTEIL6_7_1_ from Antwort antworten0_, Freiefrageantwort antworten0_1_, Einfachauswahlfrageantwort antworten0_2_, Mehrfachauswahlfrageantwort antworten0_3_, Matrixfrageantwort antworten0_4_, Zusammengesetztefrageantwort antworten0_5_, Textantwort textantwor1_, Auswahlantwort auswahlant2_ where antworten0_.id=textantwor1_.FREIEANTWORT_TEXT(+) and antworten0_.id=auswahlant2_.EINFACHAUSWANTW_AUSWAHL(+) and antworten0_.id=antworten0_1_.ID(+) and antworten0_.id=antworten0_2_.ID(+) and antworten0_.id=antworten0_3_.ID(+) and antworten0_.id=antworten0_4_.ID(+) and antworten0_.id=antworten0_5_.ID(+) and antworten0_.FRAGE_ANTWORT=?
2006-01-24 22:48:47,640 DEBUG [org.hibernate.jdbc.AbstractBatcher] preparing statement

Hallo,
ich habe mir das jetzt 5 Minuten angeguckt, aber zumindestens ich werde daraus nicht schlau.

Bitte formatiere jeden Block einzeln mit code tags.
Es ist nicht erkennbar, ob die query dadurch entsteht, dass eine Bedingung irgendwas dazu joinen muss. Vielleicht baust Du mal einen simplen Testcase, ohne if, der klar zeigt, welche Criteria query eigentlich abgefragt wid.
Mögliches Problem:
Du beziehst Dich möglicherweise auf den Frageanworttyp, für den alle Subclasses von Frage dazugejoint werden müssen.

Gruß Sebastian

Hi!

Zunächst mal vielen Dank für deine Hilfe. Also in der switch/case Anweisung wird folgender Fall ausgeführt:




Diese Bedingung bezieht sich auf ein Property der Klasse Durchfuehrung, hat also nichts mit Fragen oder Antworten zu tun.



Eine Durchfuehrung referenziert eine Umfrage. Die Umfrage muss auch bestimmte Kriterien erfüllen, die im Folgenden erläutert werden.



In diesem Teil wird die erste Abfrage ausgeführt (forUmfrSuperManager ist wahr). Das Criteria bezieht sich auf ein Property einer Umfrage, von der jeweils eine von einer Durchfuehrung referenziert wird. Es sind also die Durchfuehrungen gesucht, die auf eine Umfrage verweisen, deren Autor nicht der uId entspricht.



Diese Bedingung bezieht sich auch auf ein Property einer Umfrage. Es sind also nur die Durchfuehrungen gesucht, die eine Umfrage eines bestimmten Umfragetyps referenzieren.

Mehr Bedingungen werden nicht gestellt. Die hier berücksichtigten Bedingungen beziehen sich also nur auf Properties von Durchfuehrung und Umfrage, und nicht auf Collections. Trotzdem werden bei der Abfrage massiv Collections abgefragt und initialisiert, die von Durchfuehrung oder Umfrage verwendet werden, aber in den Mapping Dateien als "lazy" konfiguriert sind. Mir scheint, als wird diese Konfiguration völlig ignoriert.

Im Folgenden die initiale SQL-Abfrage:



Zu Beginn der Log-Datei sieht die Verarbeitung des ResultSet dann aus wie folgt:




Die Verarbeitung des ResultSet dauert etwa 5 Sekunden. Dann werden Assoziationen aufgelöst und Collection Wrapper erstellt. Im Folgenden sieht man das am Beispiel der Fragen-Collection einer Umfrage, die lazy konfiguriert wurde, oder an den lazy Collections einer Durchfuehrung: auswertungsberechtigte, antwortsaetze, bereitsabgestimmte und tanbloecke:




Nach diesen Schritten werden die angeblichen non-lazy Collections initialisiert, z. B. die Fragen-Collection einer Umfrage, die lazy konfiguriert ist, wie sich in der Umfrage-Mapping-Datei erkennen lässt:





Danach werden die Assoziationen der einzelnen Fragen aufgelöst:



Dann werden wieder non-lazy Collections initialisiert:



Bis zum Ende der Verarbeitung sind nun also gut 9 Minuten vergangen. Bei der Betrachtung der Log-Datei ist mir nun folgendes ein- bzw. aufgefallen, was vielleicht die Ursache sein könnte:

Ich bin davon ausgegangen, dass sich das mit dem lazy Attribut hierarchisch verhält - wenn das Set der Fragen lazy konfiguriert ist, werden auch nicht die Sets geladen, die zu einer Frage gehören, obwohl diese nicht lazy sind. Dies ist aber wahrscheinlich nicht der Fall...

Die Fragen einer Umfrage sind lazy:

<set name="fragen" lazy="true" inverse="true" cascade="all-delete-orphan">
<key column="FRAGE_UMFRAGE" />
<one-to-many class="Frage" />
</set>

Ein Frage enthält aber Sets, die nicht lazy sind:

<set name="auswahlMoeglichkeiten" lazy="false" inverse="true"
cascade="all-delete-orphan">
<key column="MATRIXFR_MGL" />
<one-to-many class="Auswahlmoeglichkeit" />
</set>

Eine zusammengesetzte Frage enthält z. B. sogar wieder ein non-lazy Set von Fragen....

Verhält sich also das lazy Attribut nicht so wie ich angenommen habe, sondern werden auch non-lazy Collections initialisiert, die zu Elementen einer lazy Collections gehören?


Grüße,
Matthias