Re: JDBC Large ResultSet problem + BadTimeStamp Patch
От | Peter Mount |
---|---|
Тема | Re: JDBC Large ResultSet problem + BadTimeStamp Patch |
Дата | |
Msg-id | Pine.LNX.4.21.0010111901340.8388-100000@maidast.demon.co.uk обсуждение исходный текст |
Ответ на | Re: JDBC Large ResultSet problem + BadTimeStamp Patch (Joseph Shraibman <jks@selectacast.net>) |
Список | pgsql-interfaces |
On Wed, 11 Oct 2000, Joseph Shraibman wrote: > Peter Mount wrote: > > > > On Wed, 11 Oct 2000, Michael Stephenson wrote: > > > > > Two things. > > > > > > Firstly, when dealing with a large ResultSet (about 120000 rows), I get a > > > null pointer exception on the line: > > > wasNullFlag = (this_row[columnIndex - 1] == null); > > > Whenever I call getString(), has anyone else had this? And does anybody > > > have a solution? > > > > Are you getting any out of memory errors at all? > > > > The problem with the current implementation is that it reads the entire > > result into memory, so 120000 rows may be filling up your VM's memory > > (defaults to about 16Mb). > > > > Does it occur if you add the -mx argument to java, ie: > > > > java -mx 64m uk.org.retep.sql.RetepSQL > > > > I'm in the design stage of implementing a version of ResultSet that will > > use cursors, to limit how much is loaded in memory at a time. > > > > The problem with that is the same problem I ran into with locking. > cursors need to be in a BEGIN END block, and other calls from different > Statement objects using the same db connectioni will interfere. Make > sure it is clearly documented that that will not be thread safe (unless > postgres gets named locks by then). Yes, there is a problem with multiple statements and transactions on the same connection when it comes to thread safety. The problem as I see it is two fold. 1: How to deal with two statements within one transaction. Related to this is the metadata methods that issue queries, how to deal with them while within a transaction. 2: Currently the JDBC Specs only have transactions supported at the Connection level, so I can't see how they thought that Statements could possibly run within their own transactions, unless they thought that a workaround of this is the use of batches. Peter -- Peter T Mount peter@retep.org.uk http://www.retep.org.uk PostgreSQL JDBC Driver http://www.retep.org.uk/postgres/ Java PDF Generator http://www.retep.org.uk/pdf/
В списке pgsql-interfaces по дате отправления: