PL/Java e Transazioni Distribuite

Al PGDay 2010 ho presentato un tutorial su PL/Java, una estensione Java ai linguaggi procedurali possibili in PostgreSQL. Alla fine del tutorial mi è stata rivolta una domanda interessante relativa ad un problema che non mi ero mai posto, e alla quale ho dato la risposta piu' logica secondo le mie conoscenze di PostgreSQL, di Java e di PL/Java.
Il quesito riguardava l'utilizzo di PL/java per comandare un ambiente enterprise ed eventualmente avviare una transazione distribuita. Cosa succede in questo caso? La risposta è semplice: PL/Java esegue all'interno del processo backend di PostgreSQL e quindi la transazione è confinata all'interno del backend stesso. Il processo backend non sa nulla di quello che PL/Java, che tuttavia esegue come processo esterno, sta facendo, e quindi non c'è modo di collegare la transazione/statement di PostgreSQL ad una eventuale transazione distribuita orchestrata da PL/Java. E' il programmatore PL/Java che deve farsi carico di tutto quanto.
Ad ogni modo, ho voluto chiarire questa faccenda sulla mailing list di PL/Java, qui si trova la discussione ufficiale.

Pl/Java: patch per cancellare l'operazione in corso da un trigger

Lo scorso weekend ho lavorato un po' sul codice di Pl/Java per studiare se fosse possibile cancellare una operazione in atto (statement) tramite un oggetto di tipo TriggerData. Dai test che ho effettuato posso affermare di aver raggiunto lo scopo! La patch aggiunge un paio di metodi all'interfaccia TriggerData, in particolare cancelCurrentStatement e isCurrentStatementCancelled. Questi due metodi vanno ad impostare un flag che ordina poi all'oggetto TriggerData di resituire un valore che viene interpretato come NULL al backend PostgreSQL. Così facendo si ottiene che il backend annulla l'operazione corrente. 

La patch non si conclude qui: ho anche fatto in modo che eventuali ResultSet ottenuti dopo che l'operazione è stata impostata come "cacellata" siano sempre e solo in lettura. I ResultSet ottenuti prima saranno in lettura/scrittura (ovviamente si parla di quelli new) ma ciò non costituisce un problema visto che poi l'operazione verrà comunque cancellata dal backend. Avere però un ResultSet in sola lettura aiuta a mantenere coerente l'interfaccia verso l'utente.

La patch è inserita nella coda e la si può trovare qui, dove è anche disponibile un semplice trigger per testarne il funzionamento.