OutOfMemory

["sin(EaTing)," <us...@gmail.com>]

Hi all,

I am getting into an OutOfMemory error in my case. Which is similar to the
case below. After examining the heap dump, I could find the
PreparedStatement is hold too many internal objects and might lead to the
MemoryLeak.
I am not for sure whether it is caused by my closing the statement after the
long loop, thus causing the client side of derby cashing too many things.
Will that be the problem? Thanks.

                connection.setAutoCommit(false);
                connection.setReadOnly(false);
                connection

.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);

                PreparedStatement selectProfile = connection
                        .prepareStatement(
                                "SELECT business_unit, country, bu_alias "
                                        + "FROM person WHERE email = ? "
                                        + "FOR UPDATE",
                                ResultSet.TYPE_FORWARD_ONLY,
                                ResultSet.CONCUR_UPDATABLE);
                PreparedStatement insertProfile = connection
                        .prepareStatement("INSERT INTO person(email,
business_unit, country, bu_alias) "
                                + "VALUES (?, ?, ?, ?)");

                for (int i = 0; i < aQuiteBigNumber; ++i) {
                    // omitted some code here
                    ResultSet selectProfileSet =
selectProfile.executeQuery();

                    if (selectProfileSet.next()) {
                        System.out.println("Update profile: " + email);
                        selectProfileSet.updateString(1, bu);
                        selectProfileSet.updateString(2, country);
                        selectProfileSet.updateString(3, bu_alias);
                        selectProfileSet.updateRow();
                        selectProfileSet.close();
                    }
                    else {
                        selectProfileSet.close();

                        System.out.println("Insert profile: " + email);
                        insertProfile.setString(1, email);
                        insertProfile.setString(2, bu);
                        insertProfile.setString(3, country);
                        insertProfile.setString(4, bu_alias);

                        insertProfile.executeUpdate();
                    }
                }

                selectProfile.close();
                insertProfile.close();
                connection.commit();

Re: OutOfMemory

["sin(EaTing)," <us...@gmail.com>]

Hi,

I've attached a screenshoot of the dump in tree view.
Seems NetConnection internally maintained a LinkedList which grows bigger
and bigger if the transaction is not committed.
I'll try commit in the loop.

On Fri, Jul 4, 2008 at 11:36 PM, Bryan Pendleton <bp...@amberpoint.com>
wrote:

> I am getting into an OutOfMemory error in my case. Which is similar to the
>> case below. After examining the heap dump, I could find the
>> PreparedStatement is hold too many internal objects and might lead to the
>> MemoryLeak.
>> I am not for sure whether it is caused by my closing the statement after
>> the long loop, thus causing the client side of derby cashing too many
>> things. Will that be the problem? Thanks.
>>
>
> What are the internal objects which are held? Since you've looked at
> your memory dump, can you post the number of instances of the various
> classes at the top of the list?
>
> Also, can you re-arrange your application to be able to commit during
> the loop? A single transaction cannot be arbitrarily large, as there
> are some resources that cannot be freed until the commit occurs.
>
> thanks,
>
> bryan
>
>
>

Re: OutOfMemory

[Bryan Pendleton <bp...@amberpoint.com>]

> I am getting into an OutOfMemory error in my case. Which is similar to 
> the case below. After examining the heap dump, I could find the 
> PreparedStatement is hold too many internal objects and might lead to 
> the MemoryLeak.
> I am not for sure whether it is caused by my closing the statement after 
> the long loop, thus causing the client side of derby cashing too many 
> things. Will that be the problem? Thanks.

What are the internal objects which are held? Since you've looked at
your memory dump, can you post the number of instances of the various
classes at the top of the list?

Also, can you re-arrange your application to be able to commit during
the loop? A single transaction cannot be arbitrarily large, as there
are some resources that cannot be freed until the commit occurs.

thanks,

bryan