Spring JDBC and the PostgreSQL JDBC driver
I apologize if this is not the correct place to post this question but who do I talk to about modifying the functionality of the JDBC driver?
The issue I'm running into is the interaction between the Spring Framework JDBC functionality and the PostgreSQL JDBC driver. The specific issue is that I'm using SimpleJdbcCall.execute() to call the database and getting back a Jdbc4Array. When I then try to do something like Jdbc4Array.getArray() I get a SQL error that can be tracked down to the Jdbc driver trying to use a connection object which has already been closed by the Spring Framework.
One of the benefits of the Spring Framework is that I don't have to bother with the drudge work like creating\closing connections. The drawback seems to be that the JDBC driver is making assumptions like the connection is still open.
What I 'm looking for is someone who is familiar with the JDBC driver who can say "Yes, it's worthwhile to add this functionality to the driver." Or "No, we should be looking at alternative ways to solve the problem."
"Miller, Michael W" <michael.w.miller@lmco.com> writes:
I apologize if this is not the correct place to post this question but who do I talk to about modifying the functionality of the JDBC driver?
pgsql-jdbc list would be the place for that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 4/3/2014 9:10 AM, Miller, Michael W wrote:
The issue I'm running into is the interaction between the Spring
Framework JDBC functionality and the PostgreSQL JDBC driver. The
specific issue is that I'm using SimpleJdbcCall.execute() to call the
database and getting back a Jdbc4Array. When I then try to do
something like Jdbc4Array.getArray() I get a SQL error that can be
tracked down to the Jdbc driver trying to use a connection object
which has already been closed by the Spring Framework.One of the benefits of the Spring Framework is that I don't have to
bother with the drudge work like creating\closing connections. The
drawback seems to be that the JDBC driver is making assumptions like
the connection is still open.
if that framework is opening/closing connections on every query, its
broken from a performance perspective. and if it has methods that
return objects, that are then broken, THATS also broken behavior.
but yeah, this belongs on the jdbc list.
--
john r pierce 37N 122W
somewhere on the middle of the left coast
On 04/04/14 05:39, John R Pierce wrote:
On 4/3/2014 9:10 AM, Miller, Michael W wrote:
The issue I'm running into is the interaction between the Spring
Framework JDBC functionality and the PostgreSQL JDBC driver. The
specific issue is that I'm using SimpleJdbcCall.execute() to call the
database and getting back a Jdbc4Array. When I then try to do
something like Jdbc4Array.getArray() I get a SQL error that can be
tracked down to the Jdbc driver trying to use a connection object
which has already been closed by the Spring Framework.One of the benefits of the Spring Framework is that I don't have to
bother with the drudge work like creating\closing connections. The
drawback seems to be that the JDBC driver is making assumptions like
the connection is still open.if that framework is opening/closing connections on every query, its
broken from a performance perspective. and if it has methods that
return objects, that are then broken, THATS also broken behavior.but yeah, this belongs on the jdbc list.
The framework itself (spring) has nothing to do with connections being
open/closed, that would be whatever JDBC connection pool your using
under the hood. Spring doesn't ship with a production quality
connection pool as far as I know.
I think what the OP meant to say was that with Spring your freed from
the need to always check your open connection back into the pool.
Spring is using aspect oriented magic to wrap your entry point functions
with some code that checks out a connection, starts a transaction (sets
these values as thread local objects that the rest of the framework
uses), and then has finally block that cleans it all up for you. So all
you do is mark functions that you want to open a transaction, and the
type of transaction you want. (read only, serializable, etc)
This removes all the boilerplate associated with old style JDBC. It
also means you get great reuse of your SQL code since the transaction
starts at the entry point. Most of my SQL related code is just 1 liners
using Springs JdbcTemplate class. I've written some massive
applications with this style. My current postgres project sees about
4gbps of traffic during peak times and there is not an explicit
begin/commit in the entire code base.
-Matt
On 4/3/2014 1:31 PM, Matthew Chambers wrote:
This removes all the boilerplate associated with old style JDBC. It
also means you get great reuse of your SQL code since the transaction
starts at the entry point. Most of my SQL related code is just 1
liners using Springs JdbcTemplate class. I've written some massive
applications with this style. My current postgres project sees about
4gbps of traffic during peak times and there is not an explicit
begin/commit in the entire code base.
so how does the OP use Jdbc4Array.getArray() on an object returned from
a Spring execute if Spring has automagically released/closed the connection?
--
john r pierce 37N 122W
somewhere on the middle of the left coast
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 04/04/14 10:22, John R Pierce wrote:
On 4/3/2014 1:31 PM, Matthew Chambers wrote:
This removes all the boilerplate associated with old style JDBC. It
also means you get great reuse of your SQL code since the transaction
starts at the entry point. Most of my SQL related code is just 1
liners using Springs JdbcTemplate class. I've written some massive
applications with this style. My current postgres project sees about
4gbps of traffic during peak times and there is not an explicit
begin/commit in the entire code base.so how does the OP use Jdbc4Array.getArray() on an object returned
from a Spring execute if Spring has automagically released/closed the
connection?
Well, you wouldn't be calling Jdbc4Array.getArray() anywhere in your
code where you don't have a connection, you would be doing that where
the connection is active. The connection doesn't go away until the
function that checked the connection out returns. Assuming you have a
ResultSet object you can do this:
String[] arrayOfStrings= (String[])
resultSet.getArray("col_name").getArray();
To put data into an array field, you have to use a
PreparedStatementCreator which gives you access to the
java.sql.Connection, so you can call "createArrayOf" from that.
jdbc.update(new PreparedStatementCreator() {
public PreparedStatement createPreparedStatement(final
Connection conn) throws SQLException {
final PreparedStatement ret =
conn.prepareStatement(UPDATE_TAGS);
ret.setObject(1, conn.createArrayOf("text", tags));
ret.setObject(2, id);
return ret;
}
});
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general