Paul Clapham wrote:
nikil shar wrote:was wondering if i used the last() method call on a resultset to move the cursor to the last record so i could call getRow() method to get the size of the resultset will java load the entire records returned from the database in memory first ??
basically i dont understand how last() method call works under the hood so if someone could explain in terms of resources how expensive a last() method call can be for large dataset (in my case the number of rows being returned are over 3million)
Quite likely, yes. It will at least have to read them from the database, which isn't free, and depending on how you declared the statement, it might have to store them in memory (or on disk) in case something else changes them in the database before your code gets around to actually looking at them. None of that is free.
Which is why it's a lot better to change your query to return a single row via "Select count(*) from ... ". You aren't going to process each of those three million rows individually anyway, are you? Or if you are, why do you need to know in advance how many there are going to be?
Henry Wong wrote:
nikil shar wrote:
thanks for the reply. is there a way to confirm by looking at the error message that an upgrade would fix this issue ?? I will need a good case before anyone would let me upgrade the jvm.
How about just upgrading the test environment? Or just one of the test machines? If it works, you will have a good case to upgrade it in QA, and then (after testing) in production.
Ernest Friedman-Hill wrote:No, it's not your code. Whenever the JVM crashes, it's the fault of the JVM or some native code that's being linked in; by definition Java code can't make the JVM crash.
I can see from the below that you're running 1.6.0p7; the current version is 1.6.0p23 (or 24?) The first thing I'd try is simply to bring your JVM up to date; the bug that causes the crash is likely to have been fixed in a later revision.