8.

Aplicaii distribuite bazate pe componente:

Enterprise Java Beans (EJB)
 Cuprins

8.1. Componente

8.2. Platforma Java 2 Enterprise Edition (J2EE)

8.3. Cadrul general al EJB

8.3.1. Roluri
8.3.2. Tipuri de EJB

8.4. Componente sesiune

- 8.4.1. Perspectiva clientului asupra EJB sesiune

- 8.4.2. Componente sesiune fr stare

- 8.4.3. Componente sesiune cu stare

8.5. Componente dirijate de mesaje

8.6. Persistena. Obiecte entitate

8.7. Tranzacii
 8.1. Componente

Reutilizabilitatea n POO se realizeaz numai cu anumite reguli i restricii. A aprut ideea

componentelor software ca uniti de reutilizare

Componentele software sunt uniti de compunere cu interfee specificate prin contract i

care au doar dependene de context explicite. O component software poate fi instalat
independent i poate fi utilizat de tere pri

Distribuia i instalarea componentelor se face sub form binar. O component poate fi

reimplementat i reinstalat ntr-o aplicaie fr a recompila aplicaia

Specificarea unei componente include i cerinele acesteia fa de ambiana n care va fi

utilizat (de multe ori sub forma unor proprieti, care apar ca informaii externe codului
componentei). Componenta va funciona corect numai dac aceste cerine sunt satisfcute

O alt abordare: dac ambiana n care componentele vor funciona este cunoscut, ele se
scriu innd cont de ambian i codificarea va fi mai simpl. Ambiana ofer o serie de
servicii la care componentele au acces implicit, deci n cod nu mai apare ceva explicit legat
de acestea

EJB este o tehnologie dezvoltat n spiritul componentelor. (Deosebirea fa de Java RMI i

CORBA: nu mai folosete explicit interfeele de programare pentru servicii).
 8.2. Platforma Java 2 Enterprise Edition (J2EE)(1)
O direcie a evoluiei platformei Java este
cea a suportului pentru dezvoltarea
aplicaiilor complexe din ntreprinderi.
Caracteristici (pe lng complexitate):
- Organizare multistrat: cel puin client, server
(logica de ntreprindere), baz de date
-Necesitatea consistenei permanente a datelor
(tranzacii)
- Asigurarea securitii datelor
- Scalabilitatea
Platforma Java EE are o serie de interfee
de programare (API) specifice. Cteva
dintre acestea:
- RMI creeaz baza pentru aplicaiile
distribuite, prin interfeele la distan(J2SE)
- JDBC- asigur acces portabil la bazele
de date relaionale i gestionarea
conexiunilor cu BD (J2SE)
- JNDI (Java Naming and Directory
Interface) permite accesul uniform la diverse
servicii de nume (DNS, LDAP, COS-
CORBA)
- Servlets i JSP folosite n servere Web
pentru generarea dinamic de pagini HTML
i gestionarea sesiunilor realizate prin
browsere Web
- JMS (Java Messaging Service) ofer suport
pentru aplicaii asincrone prin diverse
sisteme de mesaje. Este integrat cu EJB
bazate pe mesaje
- EJB definete un model bazat pe
componente reutilizabile pentru partea de
server (business logic) a aplicaiilor,
implementnd automat o serie de servicii i
asigurnd portabilitatea ntre diverse
servere de aplicaii. Exist EJB sesiune,
EJB bazate pe mesaje i entiti de
persisten
8.2. Platforma Java 2 Enterprise Edition (J2EE) (2)

(din Java EE6 Tutorial)

8.2. Platforma Java 2 Enterprise Edition (J2EE) (3)

(din Java EE5 Tutorial)

 8.2. Platforma Java 2 Enterprise Edition (J2EE) (4)
- Java Mail este folosit pentru a trimite
notificri prin email. Are 2 pri: una este
cea folosit de componentele aplicaiei
pentru a trimite mesaje email, cealalt este
un furnizor de servicii care permite
trimiterea mesajelor
- JAF (Java Beans Activation Framework) este
utilizat de Java Mail pentru a determina tipul
datelor din mesaje, a ncapsula accesul la
date, a descoperi operaiile disponibile
asupra lor i a crea componentele
JavaBean corespunztoare pentru aceste
operaii
- JTA (Java Transactions API) permite
demarcarea i controlul tranzaciilor n
cadrul aplicaiilor.
- Java Persistence API este soluia Java
pentru asigurarea persistenei. Folosete o
coresponden obiectual-relaional pentru
a realiza legtura ntre modelul obiectual i
BD relaionale. Are 3 pri: API propriu-zis,
limbajul de interogare i metadatele pentru
coresponden
- JAXB (Java Architecture for XML Binding)
furnizeaz un mod convenabil de a lega o
schem XML cu reprezentarea n Java. Se
poate folosi independent sau n combinaie
cu JAX-WS.
- JAX-WS definete API pe partea de client
pentru a accesa servicii Web, ca i tehnici
pentru implementarea punctelor de acces la
aceste servicii.
- JAXR (Java API for XML Registries) permite
accesul la directoarele(registrele) de uz
general din Internet. Ofer suport pentru
standardele ebXML Registry and
Repository i pentru specificaiile UDDI .
Folosind JAXR, dezvoltatorii au acces la
diverse tehnologii de directoare cu o singur
interfa
.
 8.3. Cadrul general al EJB
8.3.1. Roluri
- Arhitectura EJB permite realizarea unor
aplicaii distribuite prin combinarea de
componente dezvoltate independent, de
diferii programatori. Componentele se
dezvolt o singur dat i pot fi utilizate
(instalate) de cte ori e necesar.
- Specificarea EJB (momentan 3.1) definete
i contractele care permit ca prin
instrumentele oferite de companii diverse s
se poat dezvolta i instala componente
care interopereaz corect la execuie.
- n cadrul oferit de EJB se deosebesc 7 roluri
pe parcursul ciclului de via al unei
aplicaii:
1. Furnizorul de EJB responsabil pentru
producerea de clase Java care
implementeaz logica de business i pentru
definirea interfeelor i a descriptorului de
instalare. Este de regul un bun cunosctor
al domeniului de aplicaie.
2. Asamblorul de aplicaii combin mai
multe componente n uniti de instalare
mai mari, cu modificri n descriptorii de
instalare. Este expert n domeniul aplicaiei
3. Instalatorul (Deployer) - pornete de la
produsele furnizate de rolurile precedente i
instaleaz componentele ntr-o ambian
operaional specific. Rezolv
dependenele externe declarate de furnizorii
de componente.
4. Furnizorul serverului EJB este un
specialist n domeniul gestionrii
tranzaciilor distribuite i a altor servicii de
sistem de nivel mai sczut (productor de
SO, SGBD, middleware)
5. Furnizorul containerului EJB este
responsabil pentru punerea la dispoziie a
instrumentelor de instalare necesare i a
suportului de execuie pentru EJB.
6. Furnizorul de persisten este expert n
corespondena obiectual-relaional,
procesarea interogrilor i utilizarea cache.
7. Administratorul de sistem responsabil
pentru configurarea i administrarea
infrastructurii de calcul i de reea n care se
includ serverul i containerul EJB.
 8.3.2. Tipuri de EJB
Arhitectura EJB definete urmtoarele tipuri de
componente:
- sesiune
- dirijate de mesaje
- entitate
Caracteristicile unei componente (obiect)
sesiune:
- se execut n contul unui singur client;
- poate avea comportare tranzacional;
- actualizeaz date partajate dintr-o BD;
- nu reprezint direct date din BD;
- are durat de via relativ redus;
- dispare la o cdere a containerului EJB,
clientul trebuie s stabileasc o nou
component sesiune pentru a continua.
ntr-un container EJB se pot executa concurent
mai multe componente sesiune
Componentele sesiune pot fi: cu stare, fr
stare sau singleton
Componentele dirijate de mesaje:
- se execut la primirea unui mesaj de la un
client;
- sunt apelate asincron;
- pot fi tranzacionale;
- pot actualiza date partajate dintr-o BD;
- nu reprezint direct date din BD;
- au durat de via relativ scurt;
- nu au stare;
- dispar la o cdere a containerului de EJB,
care trebuie s le restabileasc pentru a
continua operaiile.
Componentele(obiectele) entitate:
- fac parte din modelul de domeniu,
furnizeaz o perspectiv obiectual asupra
BD;
- pot avea durat de via lung (ca i BD);
- entitatea i cheia ei primar supravieuiesc
unei cderi a containerului EJB.
 8.4. Componente sesiune
8.4.1. Perspectiva clientului asupra EJB sesiune
Pentru un client, o component sesiune este un
obiect nepersistent care implementeaz
parte din logica de business i ruleaz pe
server
Clientul nu interacioneaz direct cu obiectul
sesiune, ci prin ceea ce se numete
perspectiva clientului a acelui obiect
Un client al unui obiect sesiune poate fi local, la
distan sau un serviciu web
Un client la distan poate fi o alt EJB din
acelai sau alt container EJB, sau un
program Java arbitrar: aplicaie, applet,
servlet
Interfaa folosit de un client la distan este
implementat de container ca interfa de
business la distan, iar din perspectiva
clientului componenta este independent de
locaie
Clienii locali trebuie s se afle n acelai
container cu componenta, deci perspectiva
clientului nu este independent de locaie
Un serviciu Web poate fi client numai pentru
obiecte sesiune fr stare sau singleton.
Perspectiva unui astfel de client este descris
ntr-un document WSDL
Este posibil ca un obiect sesiune s ofere mai
multe perspective client, dar de regul ofer
una singur
Considerente pentru alegerea unei perspective:
- interfeele la distan permit o cuplare slab
ntre client i component, dar sunt potenial
costisitoare
- apelurile la distan implic transmiterea prin
valoare, ceea ce asigur o izolare ntre client
i component;
- apelurile locale implic transmitere prin
referin, deci e posibil partajarea unui
document de mari dimensiuni;
- colocarea componentei i clientului
restricioneaz distribuia componentei
- la apeluri locale se pot folosi date cu
granularitate mai fin.
 8.4.2. Componente sesiune fr stare(1)
Coninutul unei EJB:

- clasa componentei, care implementeaz

metodele de business i posibile metode cu
apel invers legate de ciclul de via al EJB;

- interfeele de business, care specific

metodele implementate de clas; nu sunt
necesare dac EJB expune doar vedere
local sau fr interfa

- clase auxiliare utilizate de clasa

componentei: clase excepii, clase utilitare
Structura unui fiier JAR pentru
Aceste elemente se mpacheteaz n fiiere EJB
JAR cu structura din figur

Ciclul de via al unei componente sesiune fr

stare este ilustrat n a doua figur.

Containerul EJB creeaz de obicei o rezerv

(pool) de componente fr stare i execut
injeciile de dependen solicitate de clieni
i apeleaz metoda adnotat
@PostConstruct. La sfritul ciclului de Ciclul de via al unei componente
via containerul EJB apeleaz metoda sesiune fr stare
adnotat @PreDestroy .
(din Java EE6 Tutorial)
 8.4.2. Componente sesiune fr stare(2)
Pentru utilizarea unei aplicaii cu EJB, aceasta
trebuie s fie instalat (deployed) ntr-un
server de aplicaii. Se folosete ca exemplu
serverul Glassfish oferit de Sun(Oracle)
Serverul se instaleaz ntr-un director, care va
apare i ca director gazd pentru Java EE.
Fiierul javaee.jar trebuie s apar n
CLASSPATH pentru a fi accesat.
n cazul Glassfish exist cteva utilitare pentru
administrarea serverului. Pornirea acestuia
se poate face cu:
asadmin start-domain domain1
iar oprirea cu:
asadmin stop-domain domain1
Etapele realizrii unei aplicaii sunt:
- se creeaz componenta EJB
- se creeaz clientul (web sau aplicaie Java)
- se instaleaz componenta EJB n server
- se ruleaz clientul (din browser sau direct).
Exemplu: convertor de valute
package com.sun.tutorial.javaee.ejb;
import java.math.BigDecimal;
import javax.ejb.*;
@Stateless
public class ConverterBean {
private BigDecimal yenRate = ...
private BigDecimal euroRate = ...
public BigDecimal
dollarToYen(BigDecimal dollars) {
BigDecimal
result=dollars.multiply(yenRate); return
result.setScale(2, BigDecimal.ROUND_UP);
}
public BigDecimal yenToEuro(BigDecimal
yen) {BigDecimal result =
yen.multiply(euroRate); return
result.setScale(2, BigDecimal.ROUND_UP);
}}
De remarcat adnotarea @Stateless la clasa
componentei. Se folosete perspectiva no-
interface
 8.4.3. Componente sesiune cu stare(1)
Ciclul de via al unei componente sesiune cu
stare este mai complex deoarece aceasta
poate fi pasivat i reactivat (v. Figura).
Doar una din metodele din figur poate fi
apelat de client (Remove), celelalte sunt
apelate doar de container

Starea unei asemenea componente (numit i

stare conversaional) se menine pe durata
unei sesiuni client-component. Dac
clientul distruge componenta (Remove),
starea dispare.
Exemplu: crucior de cumprturi pentru o
librrie online, cu componenta accesibil de
la distan
Pentru accesul de la distan este obligatorie o
interfa de business la distan (remote
business inteface), deci exist clasa
CartBean, dar i interfaa Cart. Se
folosesc 2 clase auxiliare, BookException
i IdVerifier.
De remarcat c interfaa apare ca o interfa
simpl, dar cu adnotarea @Remote:
(din Java EE6 Tutorial)
package com.sun.tutorial.javaee.ejb;
import java.util.List;
import javax.ejb.Remote;
@Remote
public interface Cart {
public void initialize(String person)
throws BookException;
public void initialize(String person,
String id)throws BookException;
public void addBook(String title);
public void removeBook(String title)
throws BookException;
public List<String> getContents();
public void remove();
}
 8.4.3. Componente sesiune cu stare(2)
Clasa CartBean implementeaz metodele
interfeei de business, dar poate
implementa i alte metode (@Remove) sau
metodele pentru apeluri inverse, adnotate
corespunztor: @PostConstruct,
@PreDestroy, etc.
Clasa CartBean trebuie adnotat cu
@Stateful
Semntura unei metode de business trebuie s
respecte urmtoarele:
- s aib nume care nu ncepe cu ejb;
- modificatorul de acces s fie public;
- dac este permis acces de la distan,
argumentele i tipul returnat trebuie s fie
legale pentru RMI;
- nu pot apare modificatorii static i final.
Clasele auxiliare pot fi puse n acelai fiier
JAR cu clasa CartBean sau ntr-un fiier
WAR sau EAR.
Clientul este realizat n clasa CartClient, cu
lansare din linia de comand. Clasa obine
o referin la un obiect CartBean prin
injecie de referin:
@EJB
private static Cart cart;
Cu aceasta apelurile la metodele de business
din CartBean apar astfel:
cart.addBook("Bel Canto");
...
List<String> bookList =
cart.getContents();
Compilarea i instalarea unei aplicaii se pot
face fie ntr-un IDE (ex. NetBeans), fie din
linie de comand, de regul cu ajutorul
utilitarului ant.
 8.5. Componente dirijate de mesaje (1)
Componentele dirijate de mesaje sunt
consumatori de mesaje dintr-o coad sau
de la un abonament de durat. Mesajele pot
fi trimise de orice component Java sau
chiar de aplicaii care nu folosesc
tehnologie Java

Componenta conine o metod onMessage,

apelat automat cnd sosete un mesaj.
Poate conine metode auxiliare pentru
prelucrarea mesajelor

Clasa component folosete adnotarea

@MessageDriven i trebuie s
implementeze interfaa
javax.jms.MessageListener

Containerul EJB este responsabil pentru

crearea unei astfel de componente i
nregistrarea ei ca receptor de evenimente

Ciclul de via al unei componente dirijate de

mesaje este redat n figur

Aplicaie simpl: un client trimite mesaje ntr-o

coad de unde sunt preluate de o
component dirijat de mesaje (din Java EE6 Tutorial)
 8.5. Componente dirijate de mesaje (2)
Clientul SimpleMessageClient ncepe cu
injectarea fabricii de conexiuni i a
resurselor cozii:
@Resource(mappedName=
"jms/ConnectionFactory")
private static ConnectionFactory
connectionFactory;
@Resource(mappedName="jms/Queue)
private static Queue queue;
Se creeaz apoi o conexiune, o sesiune, un
productor de mesaje i un mesaj:
connection =
connectionFactory.createConnection();
session =
connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
messageProducer =
session.createProducer(queue);
message = session.createTextMessage();
Se trimit apoi mesaje, ntr-un ciclu:
message.setText("This is " + (i + 1));
messageProducer.send(message);
Componenta dirijat de mesaje conine o
adnotare pentru a specifica numele JDNI al
cozii din care consum mesaje:
@MessageDriven(mappedName="jms/Queue",... )
Clasa SimpleMessageBean trebuie s
implementeze interfaa MessageListener
care conine metoda onMessage. Aceasta
este apelat de containerul EJB cnd coada
conine un mesaj. Metoda are un singur
argument de tip Message, mesajul primit, iar
valoare returnat trebuie s fie de tip void.
Partea principal din corpul metodei este:
if (inMessage instanceof TextMessage)
{ msg = (TextMessage) inMessage;
logger.info("MESSAGE BEAN: Message
received: " + msg.getText()); }
else {logger.warning("Message of wrong
type: " +
inMessage.getClass().getName());
}
logger este de tip Logger, clas din
java.util.logging, care permite
nregistrarea mesajelor ntr-un jurnal
 8.6. Persistena.
8.6.1 Obiecte entitate
O entitate reprezint o tabel dintr-o baz de
date relaional, fiecare exemplar
corespunznd unei linii din tabel.
Clasa entitate trebuie s satisfac urmtoarele
cerine:
- s fie adnotat cu
javax.persistence.Entity
- s aib un constructor no-arg public sau
protected
s nu fie declarat final i s nu aib
metode sau cmpuri persistente final
- dac se transmite prin valoare ca obiect
detaat (de ex. prin interfaa la distan) s
implementeze Serializable
- variabilele de exemplar persistente se
declar private, protected sau package
Fiecare entitate are un identificator de obiect
unic, cheia primar (simpl sau compus)
Multiplicitile n relaiile ntre entiti pot fi: one-
to-one, one-to-many, many-to-one, many-
to-many
Direcia unei relaii (partea proprietar)
stabilete modul cum se face actualizarea
n baza de date. O relaie unidirecional
are doar o parte proprietar. La relaiile
bidirecionale exist partea proprietar i
partea invers
Interogrile navigheaz frecvent prin relaii,
direcia unei relaii stabilind dac navigarea
poate avea loc. De exemplu, o interogare
poate naviga de la LineItem la Product, dar
nu invers (LineItem reprezint o linie dintr-
un Order).
Sunt permise motenirea, asocierile polimorfice
i interogrile polimorfice. Clasele entitate
pot fi abstracte sau concrete.
 8.6.2. Gestionarea entitilor(1)
Entitile sunt gestionate de managerul de
entiti, reprezentat de un exemplar al
javax.persistence.EntityManager, asociat
cu un context de persisten: setul de
entiti dintr-un depozit (data store)
Interfaa EntityManager definete metode
pentru crearea i tergerea entitilor,
cutarea entitilor dup cheia primar i
rularea unor interogri
Exist manageri de entiti gestionai de
container sau gestionai de aplicaii
Pentru cei gestionai de container contextul de
persisten este propagat automat de
container la toate componentele care
folosesc managerul ntr-o singur tranzacie publicvoidenterOrder(intcustID,OrdernewOrder)
Pentru cei gestionai de aplicaii, contextul de
persisten nu este propagat, iar ciclul de
via al managerului este gestionat de
aplicaie
Un manager gestionat de container se obine
prin injectarea lui ntr-o component a
aplicaiei:
@PersistenceContext EntityManager em;
Aplicaiile creeaz manageri de entiti folosind
metoda createEntityManager a clasei
javax.persistence.EntityManagerFactory:
@PersistenceUnit EntityManagerFactory emf;
EntityManager em =
emf.createEntityManager();
Pentru a cuta o entitate dup cheia primar
se folosete metoda EntityManager.find:
@PersistenceContextEntityManagerem;
{
Customercust=em.find(Customer.class,custID);
cust.getOrders().add(newOrder);
newOrder.setCustomer(cust);
}
 8.6.2. Gestionarea entitilor(2)
Gestionarea ciclului de via a unei entiti
Un exemplar entitate poate fi n una din
urmtoarele stri: nou, gestionat, detaat,
ters
Un exemplar nou nu are identitate persistent i
nu este nc asociat cu un context de
persisten
Entitile gestionate au identitate persistent i
sunt asociate cu un context de persisten
Entitile detaate au identitate persistent i nu
sunt momentan asociate cu un context de
persisten
Entitile terse au identitate persistent, sunt
asociate cu un context de persisten i sunt
planificate pentru tergerea din baza de date
Entitile noi devin gestionate i persistente fie
prin apelarea metodeipersist, fie printr-o
operaie persistn cascad apelat din
entiti nrudite care au setate elementele
cascade=PERSIST saucascade=ALL n
adnotarea de relaie
Datele unei asemenea entiti sunt memorate n
baza de date cnd tranzacia asociat cu
operaiapersist este terminat
Dac o entitate este deja gestionat, operaia
persisteste ignorat, dar poate avea efecte
n cascad pentru entitile nrudite
Operaia persist pe o entitate tears o face s
devin gestionat, iar pe o entitate detaat
produceIllegalArgumentException sau face
ca tranzacia s eueze
@PersistenceContextEntityManagerem;
...
publicLineItemcreateLineItem(Order
order,Productproduct,intquantity){
LineItemli=newLineItem(order,
order.getLineItems().add(li);
em.persist(li);
returnli;
}
Exemplu de adnotare pentru relaie:
@OneToMany(cascade=ALL,mappedBy="order")
publicCollection<LineItem>getLineItems(){
returnlineItems;
}
 8.6.2. Gestionarea entitilor(3)
Pentru tergerea entitilor se apeleaz metoda
remove, care poate avea i efect n cascad.
Dac metoda e apelat pe o entitate nou
este ignorat, dar poate avea efect n
cascad . Apelul pe entiti detaate se
aseamn cu apelul lui persist, iar apelul pe
entiti deja terse este ignorat. Datele
entitii vor fi terse din baza de date cnd
se termin tranzacia sau printr-o operaie
flush
n exemplul:
publicvoidremoveOrder(IntegerorderId){
try{
Orderorder=em.find(Order.class,orderId);
em.remove(order);
}...
toate entitile LineItem asociate cu comanda vor fi
terse pentru c Order.getLineItems are setat n
adnotarea de relaie cascade=ALL
Starea entitilor persistente este sincronizat cu
baza de date cnd tranzacia cu care sunt
asociat este terminat cu succes (comis).
Dac o entitate gestionat este ntr-o relaie
bidirecional cu alt entitate gestionat, date
vor deveni persistente pe baza prii de
proprietar din relaie.
Se poate fora sincronizarea prin apelarea
metodeiflush, care are efect n cascad.
Dacflush e apelat pe o entitate tears,
datele entitii se terg din baza de date
Crearea interogrilor
Pentru interogarea bazei de date prin limbajul de
interogare al Java Persistence se folosesc
metodele EntityManager.createQueryi
EntityManager.createNamedQuery.
Metoda createQuery se folosete pentru a crea
interogri dinamice, definite direct n codul
(logica de business) din aplicaie
Metoda createNamedQuery creeaz interogri
statice, definite ca metadate folosind
adnotareajavax.persistence.NamedQuery
 8.6.2. Gestionarea entitilor(4)
Exemplu de interogare dinamic: Uniti de persisten
publicListfindWithName(Stringname){ O unitate de persisten definete mulimea
returnem.createQuery(
"SELECTcFROMCustomercWHEREc.name tuturor claselor entitate care sunt gestionate
LIKE:custName") de exemplare EntityManager. Aceast
.setParameter("custName",name) mulime de clase reprezint datele dintr-o
.setMaxResults(10).getResultList(); singur baz de date (data store)
}
Unitile de persisten sunt definite n fiierul
Exemplu de interogare static: de configurarepersistence.xml. Fiierul
JAR sau directorul al crui director METAINF
@NamedQuery( care coninepersistence.xml este
name="findAllCustomersWithName", rdcina unitii de persisten
query="SELECTcFROMCustomercWHERE
c.nameLIKE:custName" Exemplu de fiier:
) <persistence>
<persistenceunitname="OrderManagement">
Exemplu de utilizare pentru@NamedQuery: <description>Thisunitmanagesordersand
customers.Itdoesnotrelyonany
@PersistenceContext Vendorspecificfeaturesandcan
publicEntityManagerem; thereforebedeployedtoany
... persistenceprovider.
customers=em.createNamedQuery( </description>
"findAllCustomersWithName") <jtadatasource>jdbc/MyOrderDB
.setParameter("custName","Smith") </jtadatasource>
.getResultList(); <jarfile>MyOrderApp.jar</jarfile>
<class>com.widgets.Order</class>
<class>com.widgets.Customer</class>
</persistenceunit>
</persistence>
 8.7 Tranzacii
Dou tipuri de tranzacii: gestionate de container n tranzaciile gestionate de componente,
i gestionate de componente demarcarea tranzaciilor se face n codul
componentei. Se elimin o limitare a
n tranzaciile gestionate de container, acesta
tranzaciilor gestionate de container, n care
fixeaz limitele unei tranzacii. Se pot folosi
o metod fie este asociat cu o singur
cu oricare din tipurile de componente. Codul
tranzacie, fie cu niciuna.
componentelor nu conine explicit marcaje
pentru delimitarea tranzaciilor La codificare trebuie decis dac se folosesc
tranzacii JDBC sau tranzacii JTA
La proiectarea componentelor se pot specifica
metodele asociate cu tranzacii, prin setarea O tranzacie JTA este controlat de managerul
atributelor de tranzacii de tranzacii al Java EE.
Posibile valori pentru atributele de tranzacii: Pe lng controlul mai fin, tranzaciile JTA
Required (implicit), RequiredNew,Mandatory, permit i actualizri n baze de date multiple
NotSupported,Supports,Never
de la productori diferii
Atributele de tranzacie se specific prin
O limitare a managerului de tranzacii: nu
adnotri:
permite tranzacii ncuibate
@TransactionAttribute(NOT_SUPPORTED)
Pentru a demarca o tranzacie JTA se folosesc
Dac apare o excepie sistem, tranzacia este metodelebegin,commit i rollback din
implicit rulat napoi (rolled back). O metod interfaa
poate cere explicit acest lucru apelnd javax.transaction.UserTransaction
metoda setRollbackOnly a interfeei
EJBContext (util la excepiile definite de
aplicaie)