Låsning

For at bruge distribuerede transaktioner skal du bruge j2ee og en applikationsserver som understøtter JTA XA (java transaction architecture - eXtended Architecture).

Jeg vil formode, at du mener 2 Phase Commit og ikke 2 Phase Locking
(det sidste har jeg aldrig hørt om).

For det først skal du gøre dig klart, at du kun har brug for
2 Phase Commit, hvis du har mere end en data ressource. Det er
ikke nødvendigt med kun en enkelt database.

For at bruge 2 Phase Commit skal:
  - du have en Transaction Manager
  - alle dine data ressourcer (typisk databaser) skal være
    XA compliant

Alle J2EE application servere har en Transaction Manager, så
i det environment er det nemt.

Men man kan også bruge 2PC i andre environments.

Det fungerer på det måde, at data ressourcerne
registerer sig hos Transaction Manager'en, du kalder
begin og commit i Transaction Manager'en, og ellers
kalder du din data ressource helt normalt.

Det *kan* jo osse lade sig gøre at kode både 2- og 3-fase commit selv, hvis man har god (rigtig god) tid. Vi lavede da en implementation på legetøjseksempler på dataingeniørstudiet. Interessant kursus...
Jeg kan bare ikke finde lærebogen lige nu. Damn.

jeg tvivler på at man selv kan implementere noget som kæmpefirmaer som IBM (MQueue) har postet flere milioner af kroner og udviklingstimer i - også selvom man har en god lærebog og god tid ;-)

Der er faktisk freeware TM'ere !

Se f.eks.:
  http://tyrex.exolab.org/

Siden du ikke kan bruge 2 Phase Commit og Transaction Manager'e
til noget - kan du uddybe lidt, hvad du søger efter ?

2 fase låsning eksisterer såvidt jeg ved også som begreb. En proces der benytter sig af 2 fase låsning kan enten være i en voksende tilstand (sætter låse) eller i en aftagende tilstande (fjerner låse).

Aha. Lyder som noget der er interessant i deadlock detecting
kode !

mfalck> Jeg påstår ikke, at man kan lave en "industrial strength"-implementering af 2PC-protokollen, men hvis det er til undervisningsbrug kan man godt lave noget, der viser funktionaliteten uden at være komplet. MQ (som tidligere hed MQSeries fra IBM) indeholder jo også andet end blot 2PC. Det er jo et skalérbart messaging og queue management-system, hvor 2PC indgår. Men jeg vil stadig påstå, at hvis det er 2PC man er ude efter, så kan det implementeres. Det er ikke specielt kompliceret begreb. Det komplicerede er at sikre, at der er "pålidelig kommunikation", dvs. at sikre, at 1) alle meddelelser kommer frem, eller 2) man ved, hvilke meddelelser, der ikke kom frem.

Rettelse: Selvfølgelig kan man lave en "industrial strength"-version. Det tager bare lang tid... ;o)

arne> Det er korrekt. Du kan lave en deadlock avoidance ved at sikre, at du tager låsene i en bestemt rækkefølge, og at du - som viht siger - ikke skiftevis tager og slipper ressourcer. Det giver naturligvis nogle begrænsninger, og der er det ultimative trade-off ved brugen af mange låse...

arne> Har du ikke et eksempel på deadlock detecting kode i java?

Jeg har ikke prøvet med deadlocks og Oracle.

Jeg ville forvente, at du laver din Java/JDBC kode
helt normalt og at du får en SQLException, hvis
Oracle detecter en deadlock.

Det nemmeste måde at fjerne deadlocks på er at undgå deadlocks. Hvis du designer din transaktionsplan rigtigt er du helt fri for at bruge detection. Men hvilken version af Oracle bruger du? Både Oracle 8 og Oracle 9 er deadlock proof på commit plan. Du skal bare sørge for din kode også er det.

( hvem bruger også oracle?:) )

viht>
Oracle skal bruges i dette projekt, derfor! Men ellers Access :P

En transaktionsplan?
Hvordan designes sådan en?

Det bestemmer du jo mere eller mindre selv.
Rent programmeringsmæssigt gælder det om at have dine inserts, updates, selects osv. grupperet rigtigt. F.eks. en opret ordre plan:

1. select for update på de varer der indgår, således du får lås på dem.
2. update lagerbeholdningen på varerne, f.eks. -2 hvis du bruger 2 stk af varen.
3. insert into Ordre selve ordren med ordreid, kundeid.. mv
4. insert into Ordrelinie alle ordrelinierne på ordren med ovenstående ordreid
5a. Hvis alt ok COMMIT
5b. ellers ROLLBACK

Her sættes alle vigtige låse først og slippes først når jeg committer. Planen kan ikke gå galt fordi vi slet ikke går i gang før alle varer er låst.

viht> Hvor ville man placere denne for update i nedenstående eksempel?

private static String INSERT = "INSERT INTO INGREDIENS (VARENR, VARENAVN, STKPRIS, ANTAL, STKPRKASSE, MINIMUMSLAGER) VALUES(?,?,?,?,?,?)";

private static String UPDATE = "UPDATE INGREDIENS SET ANTAL = ANTAL - ? WHERE VARENR =?";

private static String GET = "SELECT * FROM INGREDIENS WHERE VARENR = ?"; private static String GETALL="SELECT * FROM INGREDIENS";

:)

Jeg forstår ikke helt dit eksempel. De Strings du har der skal du vel lave nogle PreparedStatements udfra som du kan .setVærdi(...) på.

Men hvis du skal bruge et statement til select for update kan du jo bare lave en String mere.

pseudo:

private static String SELECT_FOR_UPDATE = "SELECT antal FROM <tabel> where antal = ? FOR UPDATE";

int antal = 10;
PreparedStatement ps = connection.prepareStatement(SELECT_FOR_UPDATE);
ps.setInt(1,antal);
ps.executeQuery();

Ja det er som preparedStatements
Ville gerne give dig points!
Du har rimelig styr på lortet

Tark