[Pljava-dev] Explicit transaction control

So, yea, I ran into this. And what I did was modify the source of the DB driver for PL/Java to simply ignore, rather than throw that exception.

I agree that operations that aren?t logically supported in the stored procedure simply should be ignored rather than throw an exception. I have a task ahead of me that I?ve not yet had time for to add a flag that will control this behavior. The current exception behavior makes it pretty much impossible to use any thing other than JDBC you write yourself.

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

> 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
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20131128/959ea5b5/attachment.html>