[Pljava-dev] Explicit transaction control

From: hal(dot)hildebrand at me(dot)com (Hal Hildebrand)
To:
Subject: [Pljava-dev] Explicit transaction control
Date: 2013-11-29 01:43:21
Message-ID: 0B81F467-5CD1-4EB5-B5E6-2D882CB15600@me.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pljava-dev

As to whatever the heck plpython is doing, my person belief is that you?d have to be barking mad to use such. If you get to the point where you need to do that in a stored procedure, you?re just doing it wrong ;)

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/bd300346/attachment-0001.html>

In response to

Browse pljava-dev by date

  From Date Subject
Next Message Thomas Hallgren 2013-11-29 07:54:56 [Pljava-dev] Explicit transaction control
Previous Message Hal Hildebrand 2013-11-29 01:41:11 [Pljava-dev] Explicit transaction control