[Pljava-dev] Explicit transaction control

Agreed, let's consider Connection.setAutocommit(true) which is nothing
more than user informing the connection object to automatically commit
each statement as it executes, it does not matter how we achieve this.
We can internally create savepoints/start subtransactions and
commit/rollback them depending upon how they execute. Even in normal
JDBC setAutocommit(false) means issue another BEGIN statement with the
next call, and when user issues a commit/rollback, we send another BEGIN
with next query to automatically start another transaction. This is to
ease the pain on user's end, otherwise he has the Savepoint option in
JDBC as well.

Similarly when we are not in autocommit mode (and we are not in pljava),
the user's action to connection.commit()/rollback() could be responded
with a similar way - end the current SUBTRANSACTION and start a new one.

See www.postgresql.org/docs/9.2/static/plpython-subtransaction.html the
function call is still in transaction, but they do allow exolicit
transaction control with the same backend.

-- Altaf

From: Hal Hildebrand [mailto:hal.hildebrand at me.com]
Sent: Friday, 29 November 2013 12:19 PM
To: Altaf, Muhammad
Cc: pljava-dev at lists.pgfoundry.org
Subject: Re: [Pljava-dev] Explicit transaction control

By definition, you're *already* in a transaction because you're running
your Java inside of a database session. You can use save points
<http://is.gd/mQ5ytc> (haven't tried them in pl/java). You can
save/rollback to them. But you can't nest transitions in PostgreSQL,
irregardless of the stored procedure language, or DB driver (afaik).

On Nov 28, 2013, at 4:21 PM, Altaf, Muhammad
<Muhammad.Altaf at au.fujitsu.com> wrote:

Hi,

Currently connection.commit/rollback in pljava throw
FeatureNotSupportedException because the function call is already in a
transaction so the explicit transaction control is not allowed. I was
comparing this with pl/python and found that the later actually allows
this by creating sub-transactions, which means technically it should be
possible to handle this in pljava but there should be other reasons not
to implement it.

I am willing to implement this feature if there is no philosophical
reason that discourages use of explicit transaction controls in pljava,
or some backend limitation that does not permit these controls without
putting some *hacks*.

Thoughts?

Muhammad Altaf

Fujitsu Australia Software Technology

www.fastware.com.au <http://www.fastware.com.au/>

_______________________________________________
Pljava-dev mailing list
Pljava-dev at lists.pgfoundry.org <mailto:Pljava-dev at lists.pgfoundry.org>
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
<http://lists.pgfoundry.org/mailman/listinfo/pljava-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20131129/87bb8a34/attachment.html>