From: thomas at tada.se (Thomas Hallgren) Date: Fri, 29 Nov 2013 08:54:56 +0100 Subject: [Pljava-dev] Explicit transaction control In-Reply-To: <15631647725E1342BFD5662917E1063AB45FF5@sydexchtmp4.au.fjanz.com> References: <15631647725E1342BFD5662917E1063AB45FC5@sydexchtmp4.au.fjanz.com> <15631647725E1342BFD5662917E1063AB45FF5@sydexchtmp4.au.fjanz.com> Message-ID: <52984850.2040606@tada.se> 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 (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 > 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 > > > > _______________________________________________ > 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: