agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feed[Pljava-dev] Explicit transaction control
6+ messages / 0 participants
[nested] [flat]
* [Pljava-dev] Explicit transaction control
@ 2013-11-29 00:21
0 siblings, 1 reply; 6+ messages in thread
From: @ 2013-11-29 00:21 UTC (permalink / raw)
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20131129/996e6e9f/attachment.html;
^ permalink raw reply [nested|flat] 6+ messages in thread
* [Pljava-dev] Explicit transaction control
@ 2013-11-29 01:18
parent:
0 siblings, 1 reply; 6+ messages in thread
From: @ 2013-11-29 01:18 UTC (permalink / raw)
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/3aea91c6/attachment.html;
^ permalink raw reply [nested|flat] 6+ messages in thread
* [Pljava-dev] Explicit transaction control
@ 2013-11-29 01:38
parent:
0 siblings, 3 replies; 6+ messages in thread
From: @ 2013-11-29 01:38 UTC (permalink / raw)
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;
^ permalink raw reply [nested|flat] 6+ messages in thread
* [Pljava-dev] Explicit transaction control
@ 2013-11-29 01:41
parent:
2 siblings, 0 replies; 6+ messages in thread
From: @ 2013-11-29 01:41 UTC (permalink / raw)
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;
^ permalink raw reply [nested|flat] 6+ messages in thread
* [Pljava-dev] Explicit transaction control
@ 2013-11-29 01:43
parent:
2 siblings, 0 replies; 6+ messages in thread
From: @ 2013-11-29 01:43 UTC (permalink / raw)
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;
^ permalink raw reply [nested|flat] 6+ messages in thread
* [Pljava-dev] Explicit transaction control
@ 2013-11-29 07:54
parent:
2 siblings, 0 replies; 6+ messages in thread
From: @ 2013-11-29 07:54 UTC (permalink / raw)
Not sure what advantage a subtransaction would bring besides non-standard calls. JDBC has savepoints and PL/Java
supports them. What do you need besides this?
Savepoint sp = conn.setSavepoint();
try {
...
conn.releaseSavepoint(sp);
} catch(SQLException e) {
conn.rollback(sp);
}
- thomas
On 2013-11-29 02:38, Altaf, Muhammad 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 <mailto: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
>
>
>
> _______________________________________________
> 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/20131129/d4680b2c/attachment-0001.html;
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2013-11-29 07:54 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2013-11-29 00:21 [Pljava-dev] Explicit transaction control
2013-11-29 01:18 `
2013-11-29 01:38 `
2013-11-29 01:41 `
2013-11-29 01:43 `
2013-11-29 07:54 `
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox