Michael Schmid, Senior Consulting bei Trivadis, über APEX-Transaktionen sowie das Session State Handling

1. 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 Schmid
Senior Consultant
… und über das Session State Handling erfahren wollten

2. 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

3. 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.

4. 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

5. Was Sie schon immer über APEX-Transaktionen wissen wollten5 20.04.15
Transaktionen
und das ACID-Prinzip

6. Transaktionen und das ACID-Prinzip
Die Theorie
Was Sie schon immer über APEX-Transaktionen wissen wollten6 20.04.15
„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.

7. Transaktionen und das ACID-Prinzip
Ein praktisches Beispiel
Was Sie schon immer über APEX-Transaktionen wissen wollten7 20.04.15
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

8. Was Sie schon immer über APEX-Transaktionen wissen wollten8 20.04.15
Wie verwaltet APEX Transaktionen?

9. Wie verwaltet APEX Transaktionen?
Was wir erwarten würden…
Was Sie schon immer über APEX-Transaktionen wissen wollten9 20.04.15
Eine Transaktion!
… oder:
Mehrere Transaktionen?
Hinsichtlich des DML gegen die
„eigenen“ Tabelle(n)?
Hinsichtlich der Veränderung
des Session State?

10. Wie verwaltet APEX Transaktionen?
Was Sie schon immer über APEX-Transaktionen wissen wollten10 20.04.15
Im Debug sehen wir für das Page Rendering…
… und im Page Processing:

11. Wie verwaltet APEX Transaktionen?
Was Oracle dazu sagt…
Was Sie schon immer über APEX-Transaktionen wissen wollten11 20.04.15
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.

12. Wie verwaltet APEX Transaktionen?
Was Oracle dazu sagt…
Was Sie schon immer über APEX-Transaktionen wissen wollten12 20.04.15
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)

13. Wie verwaltet APEX Transaktionen?
Was Oracle dazu sagt…
Was Sie schon immer über APEX-Transaktionen wissen wollten13 20.04.15
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

14. Wie verwaltet APEX Transaktionen?
… und wie es im Überblick tatsächlich ist
Was Sie schon immer über APEX-Transaktionen wissen wollten14 20.04.15
COMMIT
Page Processing
Kein Fehler
COMMIT
ROLLBACK
Unbehandelte Exception
Page
Submit
Computations
Validations
Processes
Dynamic
execution of
SQL and
PL/SQL
COMMIT
(wenn Session State geändert)
COMMIT
(wenn Session State geändert)
COMMIT
(wenn Session State geändert)
Itemwerte werden in den Session
State übertragen

15. Was Sie schon immer über APEX-Transaktionen wissen wollten15 20.04.15
Wie funktioniert‘s im Detail?

16. Wie funktioniert‘s im Detail?
Wie APEX den Session State verwaltet…
Was Sie schon immer über APEX-Transaktionen wissen wollten16 20.04.15
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.

17. Wie funktioniert‘s im Detail?
Wie APEX SQL und PL/SQL ausführt (I)
Was Sie schon immer über APEX-Transaktionen wissen wollten17 20.04.15
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 mit
DBMS_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

18. Wie funktioniert‘s im Detail?
Wie APEX SQL und PL/SQL ausführt (II)
Was Sie schon immer über APEX-Transaktionen wissen wollten18 20.04.15
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.

19. Was Sie schon immer über APEX-Transaktionen wissen wollten19 20.04.15
Einige Probleme und wie man sie
vermeiden kann

20. Einige Probleme und wie man sie vermeiden kann
Computations werden nicht zurückgerollt
Was Sie schon immer über APEX-Transaktionen wissen wollten20 20.04.15
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.

21. Einige Probleme und wie man sie vermeiden kann
Validations können den Session State verändern und COMMITs auslösen
Was Sie schon immer über APEX-Transaktionen wissen wollten21 20.04.15
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?

22. Einige Probleme und wie man sie vermeiden kann
Mischen von Bind-Syntax und Prozeduraufrufen zum Ändern des Session State I
Was Sie schon immer über APEX-Transaktionen wissen wollten22 20.04.15
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;

23. Einige Probleme und wie man sie vermeiden kann
Mischen von Bind-Syntax und Prozeduraufrufen zum Ändern des Session State II
Was Sie schon immer über APEX-Transaktionen wissen wollten23 20.04.15
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);

24. Einige Probleme und wie man sie vermeiden kann
Automatic Row Processing mit Return Key führt COMMIT aus
Was Sie schon immer über APEX-Transaktionen wissen wollten24 20.04.15
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.

25. Was Sie schon immer über APEX-Transaktionen wissen wollten25 20.04.15
Oracles Antwort
oder:
Das Schicksal eines
Service Requests

26. Oracles Antwort
oder: Das Schicksal eines Service Requests
Was Sie schon immer über APEX-Transaktionen wissen wollten26 20.04.15
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:

27. Was Sie schon immer über APEX-Transaktionen wissen wollten27 20.04.15
Fazit

28. Fazit
Was Sie schon immer über APEX-Transaktionen wissen wollten28 20.04.15
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?

29. Fragen und Antworten
Michael Schmid
Senior Consultant
Tel. +49-162-291 47 61
michael.schmid@trivadis.com
20.04.15 Was Sie schon immer über APEX-Transaktionen wissen wollten35