Was Sie schon immer über APEX-Transaktionen wissen wollten

BASEL BERN BRUGG DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. GENF

HAMBURG KOPENHAGEN LAUSANNE MÜNCHEN STUTTGART WIEN ZÜRICH

Was Sie schon immer über APEX-

Transaktionen wissen wollten

Michael SchmidSenior Consultant

… und über das Session State Handling erfahren wollten

Unser Unternehmen.

© Trivadis – Das Unternehmen (Kurzpräsentation)2 5/4/2016

Trivadis ist führend bei der IT-Beratung, der Systemintegration, dem Solution

Engineering und der Erbringung von IT-Services mit Fokussierung auf -

und -Technologien in der Schweiz, Deutschland, Österreich und

Dänemark. Trivadis erbringt ihre Leistungen aus den strategischen Geschäftsfeldern:

Trivadis Services übernimmt den korrespondierenden Betrieb Ihrer IT Systeme.

B E T R I E B

KOPENHAGEN

MÜNCHEN

LAUSANNE

BERN

ZÜRICH

BRUGG

GENF

HAMBURG

DÜSSELDORF

FRANKFURT

STUTTGART

FREIBURG

BASEL

WIEN

Mit über 600 IT- und Fachexperten bei Ihnen vor Ort.

© Trivadis – Das Unternehmen (Kurzpräsentation)3 5/4/2016

14 Trivadis Niederlassungen mit

über 600 Mitarbeitenden.

Über 200 Service Level Agreements.

Mehr als 4'000 Trainingsteilnehmer.

Forschungs- und Entwicklungsbudget:

CHF 5.0 Mio.

Finanziell unabhängig und

nachhaltig profitabel.

Erfahrung aus mehr als 1'900 Projekten

pro Jahr bei über 800 Kunden.

Agenda

Was Sie schon immer über APEX-Transaktionen wissen wollten4 20.04.15

1. Transaktionen und das ACID-Prinzip

2. Wie verwaltet APEX Transaktionen?

Was wir erwarten würden…

Was Oracle dazu sagt…

… und wie es im Überblick tatsächlich ist.

3. Wie funktioniert‘s im Detail?

Wie APEX den Session State verwaltet…

… und SQL und PL/SQL ausführt

4. Einige Probleme und wie man sie vermeiden kann

5. Oracles Antwort oder: Das Schicksal eines Service Requests

6. Fazit


Transaktionen

und das ACID-Prinzip

Transaktionen und das ACID-PrinzipDie Theorie


„Als Transaktion […] bezeichnet man […] eine Folge von Programmschritten, die

als eine logische Einheit betrachtet werden, weil sie den Datenbestand nach

fehlerfreier und vollständiger Ausführung in einem konsistenten Zustand

hinterlassen. Daher wird für eine Transaktion insbesondere gefordert, dass sie

entweder vollständig und fehlerfrei oder gar nicht ausgeführt wird.“ (Wikipedia)

Transaktionen müssen dem ACID-Prinzip unterliegen:

– Atomicity (Atomarität) Transaktionen werden ganz oder gar nicht ausgeführt.

– Consistency (Konsistenz) Transaktionen überführen das System von einem

konsistenten Zustand in einen neuen konsistenten Zustand.

– Isolation (Isolation) Gleichzeitige Transaktionen beeinflussen sich nicht

gegenseitig.

– Durability (Dauerhaftigkeit) Erfolgreiche Transaktionen sind dauerhaft.

Transaktionen und das ACID-PrinzipEin praktisches Beispiel


Der Überweisungsvorgang besteht aus drei

Schritten.

Es dürfen entweder werden alle Schritte oder

keiner durchgeführt.

Bei einem Fehler z.B. zwischen Abbuchung

und Gutschrift wird die gesamte bisherige

Transaktion – und die Abbuchung –

zurückgerollt.

Die erfolgreiche und vollständige Transkation

ist gegen Desaster etc. geschützt und damit

dauerhaft.

Transaktionsbeginn

Buche Betrag vom Quellkonto ab

Schreibe Betrag beim Zielkonto gut

Protokolliere die Überweisung

Transaktionsende


Wie verwaltet APEX Transaktionen?

Wie verwaltet APEX Transaktionen?Was wir erwarten würden…


Eine Transaktion!

… oder:

Mehrere Transaktionen?

Hinsichtlich des DML gegen die

„eigenen“ Tabelle(n)?

Hinsichtlich der Veränderung

des Session State?

Wie verwaltet APEX Transaktionen?


Im Debug sehen wir für das Page Rendering…

… und im Page Processing:

Wie verwaltet APEX Transaktionen?Was Oracle dazu sagt…


Im Application Builder User’s Guide (Version 5.0) findet man kaum Informationen:

„If a validation fails, page processing stops, a rollback is issued, and the page

displays the error.“

Page 16-22

„Error Message - Enter the error message for this process. This message displays if

an unhandled exception is raised. After any error processing stops, a rollback is

issued and an error message displays.“

Page 17-19/20, 25-21

Die offizielle Dokumentation ist deshalb wenig nützlich.



Im Thread “When commit is executed?” (eröffnet am 19.9.2008) finden wir die

folgenden Aussagen von Scott Spadafore (†), damals ein Entwickler von APEX:

„Commits are performed when you

explicitly issue them or

when you alter session state with assignment statements,

"select into" queries, or

OUT variable assignments to bind-variable notated page- or application-item

names or

when you call apex_util.set_session_state.

If you don't do any of that, no commits happen until the page processing completes.“

(20.9.2008, 11:12)



In einem weiteren Beitrag zu diesem Thema schreibt Scott:

„… The "returning into" option on a DML process will cause a commit as it is one of

those session state altering actions. …

The session state altering transactions are not autonomous. They should be but

they aren't. …

Commits are not performed at the end of each process. They happen only in the

cases I listed.”

(28.9.2008 21:00)

Den Thread findet man unter:

https://community.oracle.com/thread/710781

Wie verwaltet APEX Transaktionen?… und wie es im Überblick tatsächlich ist


COMMIT

Page ProcessingKein Fehler

COMMIT

ROLLBACK

Unbehandelte Exception

Page

Submit

Computations

Validations

Processes

Dynamic

execution of

SQL and

PL/SQL

COMMIT(wenn Session State geändert)



Itemwerte werden in den Session

State übertragen


Wie funktioniert‘s im Detail?

Wie funktioniert‘s im Detail?Wie APEX den Session State verwaltet…


Neuer Wert für

Page- oder

Application-

Item X

Computation Ergebnis

OUT-Wert eines Prozesses

APEX_UTIL.SET_SESSION_STATE

Session

State

SELECTion des

alten (falls

vorhanden)

Itemwerts aus

dem Session

State

Neuer Wert

=

Alter Wert?

NULL ist gleich NULL

in diesem Fall!

Es wird keine

Aktion

durchgeführt.

(seit 4.1.1)

Ja

Nein

INSERT oder

UPDATE gegen

den Session

State

COMMIT

Ein (momentan) nicht

existierender Wert wird wie NULL behandelt.

Wie funktioniert‘s im Detail?Wie APEX SQL und PL/SQL ausführt (I)


Pro Item

Ermittlung der Bind-Variablen (Items)

Parsing of PL/SQL with DBMS_SYS_SQL.PARSE

Session

State

Abrufen der aktuellen Werte der Items aus dem

Session State, Binden der Werte mitDBMS_SYS_SQL.BIND_VARIABLE

(und Merken im Speicher, seit 4.1.1).

begin

select ...

into :P1_ITEM_A

...;

:P1_ITEM_B := ...;

end;

P1_ITEM_A, P1_ITEM_B, ...

Ausführung mit DBMS_SYS_SQL.EXECUTE

PROCEDURE anonymous(

P1_ITEM_A IN OUT VARCHAR2,

P1_ITEM_B IN OUT VARCHAR2,

...

) IS

BEGIN

/* your code using

P1_ITEM_A, P1_ITEM_B

etc.

*/

END;Auslesen der OUT-Werte mit

DBMS_SYS_SQL.VARIABLE_VALUE

Sichern des neuen Werts

im Session State

COMMIT,

falls neuer

Wert != alter

Wert im

Session

State

Seit 4.1.1:

IN != OUT?

Ja

Vor 4.1.1

Keine

Aktion

Nein

Wie funktioniert‘s im Detail?Wie APEX SQL und PL/SQL ausführt (II)


Diese Vorgehensweise wird offensichtlich nahezu überall in APEX verwendet:

Computations

(insbesondere Typ “PL/SQL Function Body”)

Validations

(insb. Typen “Function Returning Boolean” und “Function Retuning Error Text”)

Processes:

– PL/SQL Processes,

– On-Demand Page oder Application Processes

– Dynamic Actions vom Typ “Execute PL/SQL Code”

Im Page Rendering läuft es genauso, d.h. wenn der Session State tatsächlich

verändert wird, führt APEX ein COMMIT aus.


Einige Probleme und wie man sie

vermeiden kann

Einige Probleme und wie man sie vermeiden kannComputations werden nicht zurückgerollt


Wenn die Ausführung einer Computation nicht zu einer unbehandelten Exception

führt, dann wird das Ergebnis unmittelbar in den Session State weggeschrieben

und committed – falls der Wert sich dadurch ändert (seit 4.1.1).

Jede Computation läuft dadurch (meist) in ihrer „eigenen“ Transaktion.

Das Scheitern einer Computation beeinflusst folglich nicht die Ergebnisse/Aktionen

vorhergehender Computations.

Nachfolgende, gescheiterte Validations oder Processes, die ein ROLLBACK

auslösen, beeinflussen die Computation nicht mehr.

Kein „transaktionales“ Verhalten von Computations

erwarten oder voraussetzen.

Einige Probleme und wie man sie vermeiden kannValidations können den Session State verändern und COMMITs auslösen


Wenn eine Validation vom Typ “Function Returning Boolean” oder “Function

Returning Error Text” erfolgreich ausgefürht wurde und dabei Werte von Items

verändert hat, wird die Änderung unmittelbar in den Session State weggeschrieben

und committed – falls der Wert sich dadurch ändert (seit 4.1.1).

Nachfolgende, gescheiterte Validations oder Processes, die ein ROLLBACK

auslösen, tangieren nicht mehr die Veränderungen, die die Validation durchgeführt

hat.

Vorsicht bei DML in Validations und Veränderungen

am Session State – ist es wirklich notwendig?

Einige Probleme und wie man sie vermeiden kannMischen von Bind-Syntax und Prozeduraufrufen zum Ändern des Session State I


Betrachten wir das folgende PL/SQL eines Prozesses:

Aufrufe von Prozeduren von APEX_UTIL wie SET_SESSION_STATE,

CLEAR_APP_CACHE, CLEAR_PAGE_CACHE und CLEAR_USER_CACHE lösen mglw.

ein COMMIT aus, aber die Änderungen gegen den Session State können (teilweise)

wieder überschrieben werden durch APEX’s Behandlung der OUT-Werte der Bind-

Variablen.

Methoden zum Zugriff auf den Session State nicht mischen.

:P5_ITEM_A := UPPER(:P5_ITEM_A);

IF :P5_ITEM_A = 'ABC' THEN

APEX_UTIL.SET_SESSION_STATE('P5_ITEM_A', 'XXX');

ELSE

APEX_UTIL.SET_SESSION_STATE('P5_ITEM_A', 'WWW');

END IF;

Einige Probleme und wie man sie vermeiden kannMischen von Bind-Syntax und Prozeduraufrufen zum Ändern des Session State II


Betrachten wir z.B. das folgende PL/SQL eines Prozesses:

Der Wert der Bind-Variable für das Items wird u.U. geändert. Dadurch kann sich

der OUT-Wert der Variable vom IN-Wert unterscheiden.

Der Session State der Seite wird im Rahmen des Prozesses in jedem Fall gelöscht

und damit auch der Wert des Items im Session State.

Dies kann jedoch nur vorübergehend sein – im Rahmen der Behandlung der

Verarbeitung der OUT-Werte schreibt APEX u.U. z.B. den Wert „abcWWW“ für das

Item in den Session State.

IF length(:P5_ITEM_A) < 10 THEN

:P5_ITEM_A := :P5_ITEM_A || 'WWW';

END IF;

APEX_UTIL.CLEAR_PAGE_CACHE(5);

Einige Probleme und wie man sie vermeiden kannAutomatic Row Processing mit Return Key führt COMMIT aus


Dieser Prozess führt ein COMMIT aus, falls

der Wert im Session State sich von dem

(neuen) Schlüsselwert unterscheidet.

Dies wird im Normalfall (z.B. Schlüssel aus

Sequence) praktisch immer der Fall sein.Folgende Prozesse, die ein ROLLBACK

auslösen, rollen die Modifikationen des

Automatic DML-Prozesses nicht zurück.

Nur verwenden, wenn nötig.

Schlüsselwert vorher z.B. mit Computation

aus Sequence besorgen.


Oracles Antwort

oder:

Das Schicksal eines

Service Requests

Oracles Antwortoder: Das Schicksal eines Service Requests


SR 3-4905002531 : APEX commit behavior

The commit behavior of APEX seems to be pretty strange. It seems to be

committing while page processing whenever a real change is made in the session

cache. The desired behavior would be that the whole page processing is ONE

transaction, i.e. the developer decides if and when to commit.

Und das kam schließlich raus:


Fazit

Fazit


Das Transaktionsverhalten von APEX ist nicht (komplett) intuitiv…

– … es ist momentan sicher keine Stärke von APEX. Traurig, aber wahr.

– … es ist fast nicht dokumentiert.

– … es kann zu ernstzunehmenden Fehlern führen, die schwer aufzuspüren, zu

beheben und zu erklären sind.

Wenig ist sicher…

Dinge haben sich verändert, verändern sich und werden sich ändern:

– Z.B. die Modifikation von 4.1.0 4.1.1

– Wenn Sie einen Fall finden, der den Ausführungen hier widerspricht oder neue

Aspekte dieser Problematik beleuchtet – bitte lassen Sie es mich wissen.

Und: Hope for the best… ;-)

– APEX 5.1?

Fragen und AntwortenMichael Schmid

Senior Consultant

Tel. +49-162-291 47 61

[email protected]

20.04.15 Was Sie schon immer über APEX-Transaktionen wissen wollten35

Was Sie schon immer über APEX-Transaktionen wissen wollten

Presentations & Public Speaking

Transcript of Was Sie schon immer über APEX-Transaktionen wissen wollten