Seit der Version 3.2 können verschiedene ByteCode-Provider eingesetzt werden. So kann der Standard-Provider CGLIB durch z.B. javassist ersetzt werden. Diese Einstellung wird über den Parameter “hibernate.bytecode.provider” in der Hibernate-Konfiguration geregelt:

hibernate.bytecode.provider = cglib | javassist

Im JBoss-Server wird diese Einstellung standardmäßig auf javassist gestellt. Da dies jedoch teilweise noch Probleme gibt, vor allem bei RMI-Anwendungen, kann dies über die persistence.xml entsprechend angepasst werden. In der Version 4.0.4.GA vom JBoss produziert JavaAssist bei jeder Abfrage eine Unmenge an Klassen, die dann den PermGen Space zum Überlauf bringen.

Wie bereits bei Caching von EJB3 EntityBeans geschrieben, können diese im JBoss gecached werden. Zusätzlich ist es auch möglich häufige Datenbankabfragen zu cachen. Wenn man den JBoss und seine persistence.xml gemäß der Anleitung ist automatisch alles für das Caching von Abfragen eingestellt.
Jetzt muss bei einer Abfrage lediglich das Attribute CacheAble gesetzt werden:

Criteria crit = session.createCriteria(Entity.class);
crit.setCacheable(true);

Zusätzlich kann auch noch mit setCacheRegion die CacheRegion im TreeCache gesetzt werden.
Bei der Verwendung von ResultTransformer muss noch die Referenz beachtet werden. Der Transformer wird als Parameter mit verwendet und muss für ein erfolgreiches Caching daher immer der Gleiche sein. Unter dem Interface “Criteria” werden verschiedene Transformer angeboten. Z.B. unter Criteria.DISTINCT_ROOT_ENTITY der DistinctRootEntityResultTransformer.

Wichtig bei der Verwendung von Beziehungen unter Entitäten bei Hibernate ist die korrekte Definition wer Parent und wer Child ist. Davon abhängig ist, wie und wer die Beziehung in der Datenbank gepflegt wird und welche SQL-Statements ausgeführt werden.
Parents pflegen dabei die Beziehung in der Datenbank und Childs müssen lediglich in den Valueobjekten gepflegt werden.
Wir haben z.B. eine Klasse A, welche eine 1:m Beziehung zu B hat. Das heißt jedes B hat genau ein A, aber ein A kann bei mehreren B genutzt werden.
Dies sieht dann ungefähr so aus:
(weiterlesen…)

Hin und wieder hat man bei @ManyToOne und @ManyToMany Beziehungen zwischen Entitäten auch noch Attribute zu hinterlegen. Ein weiterer Anwendungsfall, dann halt ohne Attribute, ist die Auslagerung der ManyToOne-Beziehung in eine eigene Tabelle. Hibernate, welches mit dem JBoss 4.0.4.GA ausgeliefert wird, unterstützt leider derzeit noch keine @JoinTable in Verbindung mit @OneToOne oder @ManyToOne. Das Mapping wird beim Deployment mit folgendem Fehler quittiert:

org.hibernate.cfg.NotYetImplementedException: association table on a single ended association is not yet supported

Es bleibt einem daher nichts anderes übrig, als die Beziehung als eigene Entität zu implementieren. In unserem Beispiel haben wir hier eine Klasse A und eine Klasse B, welche zusammen die Beziehung ManyToOne haben und diese in der Tabelle A2B gespeichert wird. Die Klassen sehen dann so aus:

@Entity
public class A {
    @Id
    private int id;

    @OneToOne(fetch = FetchType.LAZY, mappedBy = “a”)
    private A2B a2b;
}

@Entity
public class B {
    @Id
    private int id;

    @OneToOne(fetch = FetchType.LAZY, mappedBy = “b”)
    private A2B a2b;
}

@Entity

public class A2B {
    @EmbeddedId
    @AttributeOverrides( {
        @AttributeOverride(name = “aId”, column = @Column(nullable = false)),
        @AttributeOverride(name = “bId”, column = @Column(nullable = false))
    })
    private A2BId id;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = “aId”, insertable = false, updatable = false)
    private A a;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = “bId”, insertable = false, updatable = false)
    private B b;
}

@Embeddable

public class A2BId implements Serializable {
    private int aId;
    private int bId;

    @Override
    public boolean equals(Object other) {
        if ((this == other))
            return true;
        if ((other == null))
            return false;
        if (!(other instanceof A2BId))
            return false;
        A2BId castOther = (A2BId) other;
        return (aId == castOther.aId) && (bId == castOther.bId);
    }

    @Override
    public int hashCode() {
        int result = 17;
        result = 37 * result + aId;
        result = 37 * result + bId;
        return result;
    }
}

Wichtig hierbei ist der eigene PrimaryKey in Form eines @Embeddable - Objektes sowie das doppelte Mapping der Primary-Key-Spalten in der Beziehungstabelle. Wichtig ist hier, dass insertable und updateable beim zweiten Mapping auf false sind:

@JoinColumn(name = “aId”, insertable = false, updatable = false)

An die Klasse A2B könnten nun noch die angesprochenen weiteren Attribute gehangen werden zu der Beziehung. Um aus der ManyToOne eine ManyToMany-Beziehung auf Seiten von A und B zu machen, muss dort lediglich eine Collection der entsprechenden Beziehungsklasse angelegt werden und entsprechend statt mit @OneToOne mit @OneToMany gemappt werden.

Mit Hilfe von EJB3 können endlich Entity-Beans mit Hilfe von Annotations beschrieben werden. Nach der neusten und letzten Definition des Standards wird jetzt jedoch anhand der Stelle der Annotations (ob am Feld oder am Getter) entschieden womit der Persistenzmanager arbeitet. Dieses Verfahren darf jedoch nicht gemischt werden. Pro Entity muss man sich daher auf Field oder auf Getter festlegen. Anderenfalls kann es zu verwunderlichen Problemen kommen, die sich dann wie folgt äußern:

Caused by: java.sql.SQLException: Invalid column name 'createDate'.

Problem hierbei ist folgender Code:

@Entity
@Table(name = "customers")
public class Customer implements Serializable {

    private static final long serialVersionUID = 2005121501L;

    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    @Column(name = “customer_id”)
    private int id;

    @Column(name = “customer_name”, nullable = false)
    private String name;

    private Date createDate;

    public int getId() {
        return id;
    }

    private void setId(int id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Column(name = “create_date”, nullable = false)
    public Date getCreateDate() {
        return createDate;
    }

    public void setCreateDate(Date createdate) {
        this.createDate = createdate;
    }
}

Hier wird die Annotation über getCreateDate ignoriert, da für die Klasse eine Fieldinvocation gewählt wurde. Ausschlaggebend dafür ist bei der Hibernateimplementierung wo der @ID-Tag steht. Die Folge ist daher, dass das Feld

    private Date createDate;

implizit gemappt wird auf das Datenbankfeld “createDate”, welches nicht existiert.
EntityBeans sollten also mit größtmöglicher Sorgfalt überprüft werden.