Java Planet

Jak wiadomo korzystanie z JPA, niesie z sobą bardzo wiele udogodnień, np.: umożliwia w miarę bezbolesne połączenie świata relacyjnego (baza danych) z światem obiektowości (java). Niestety jak każde rozwiązanie tego pociąga za sobą narzut wydajnościowy, szczególnie widoczny w czasie masowych operacji.

Jeśli jednak nasze operacje są typu “readonly”, czyli używamy JPA tylko do pozyskiwania encji z bazy danych, a samych obiektów nie modyfikujemy/tworzymy/usuwamy – możemy wykorzystać pewne rozszerzenie Toplinka. W momencie gdy uda nam się “poinformować toplink”, że pewien rodzaj encji (konkretna klasa) nie będzie przez nas modyfikowana, może on zaniechać czasochłonnego tworzenia klonów, sprawdzania czy encja została zmodyfikowana, itp. Wszystko to wpłynie pozytywnie na wydajność naszej aplikacji. Uzyskamy lepszy czas tworzenia nowych encji, a także krótszy czas w którym transakcja (unitOfWork) jest zamykana.

Oczywiście nie wszystkie operacje (typy encji) muszą być typu “readonly”. W poniższym przypadku encją “readonly” jest eu.swierczyna.entity.Server, natomiast encje eu.swierczyna.entity.LogEntry są swobodnie modyfikowane wewnątrz projektu.

persistence.xml (kluczowa linia 12)

<persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
 version="1.0">
   <persistence-unit name="myUnitPU" transaction-type="JTA">
   <jta-data-source>jdbc/test</jta-data-source>
   <class>eu.swierczyna.entity.Server</class>
   <class>eu.swierczyna.entity.LogEntry</class>
   <exclude-unlisted-classes>true</exclude-unlisted-classes>

   <properties>
      <!--  readonly entity: Server -->
      <property name="toplink.descriptor.customizer.Server" value="eu.swierczyna.ReadOnlyEntityCustomizer"/>
   </properties>
   </persistence-unit>
</persistence>

ReadOnlyEntityCustomizer.java z implementacją własnego EntityCustomizera. Może być wspólny dla wielu typów encji.

package eu.swierczyna;

import oracle.toplink.essentials.descriptors.ClassDescriptor;
import oracle.toplink.essentials.tools.sessionconfiguration.DescriptorCustomizer;

public class ReadOnlyEntityCustomizer implements DescriptorCustomizer {

	public void customize(ClassDescriptor desc) throws Exception {
		desc.setReadOnly();
	}
}

Dokumentacja dotycząca wydajności toplink-unitOfWork.

Kolejnym sposobem na zwiększenie wydajności wydaje się być implementacja własnego AttributeChangeTrackingPolicy. Niestety w tym temacie nie mam własnych doświadczeń.