TopLink errors and memory leaks 
Author Message
 TopLink errors and memory leaks

Hey,

I'm using TOPLink with VAST 55...  I've found a memory leak; it's not
in the Smalltalk image, but rather it happens when TOPLink fails to
free a statement handle on an error.  Have any of you run into this?
The test I set up executes some bad SQL, the database returns an error
which is in turn handled (ignored) by my app.  When the error is in a
loop the memory climbs; taking a look at the ODBC trace shows that
statement handles allocated for the (bad) sql statment are never
freed, but are properly freed for regular (good) sql statments.

This could very easily be a problem in my application code, but I
thought I'd ask if anyone had come accross this before.

Thanks,
Mike B.



Sun, 17 Apr 2005 07:40:18 GMT  
 TopLink errors and memory leaks

Quote:

> I'm using TOPLink with VAST 55...  I've found a memory leak; it's not
> in the Smalltalk image, but rather it happens when TOPLink fails to
> free a statement handle on an error.  Have any of you run into this?
> The test I set up executes some bad SQL, the database returns an error
> which is in turn handled (ignored) by my app.  When the error is in a
> loop the memory climbs; taking a look at the ODBC trace shows that
> statement handles allocated for the (bad) sql statment are never
> freed, but are properly freed for regular (good) sql statments.

> This could very easily be a problem in my application code, but I
> thought I'd ask if anyone had come accross this before.

I vaguely recall having problems with ODBC (years ago).
I can't recall the details, but they were solved by
using updated ODBC drivers from the database vendor,
instead of using the Microsoft supplied driver.
--yanni


Sun, 17 Apr 2005 11:27:47 GMT  
 TopLink errors and memory leaks
Had the same problem with the Sybase driver a few years ago.  If you
do an allInstances of the Error that is being generated I'm willing to
bet that you will find that it is creating the Error over and over
again.  In the case mentioned above, the error severity was pretty
high and as far as I can remember, the only way to stop the errors
from being created was to disconnect the connection, and create a new
one.  This was fixed when we went to ODBC.  
Good Luck
Don Stacy
Quote:


>> I'm using TOPLink with VAST 55...  I've found a memory leak; it's not
>> in the Smalltalk image, but rather it happens when TOPLink fails to
>> free a statement handle on an error.  Have any of you run into this?
>> The test I set up executes some bad SQL, the database returns an error
>> which is in turn handled (ignored) by my app.  When the error is in a
>> loop the memory climbs; taking a look at the ODBC trace shows that
>> statement handles allocated for the (bad) sql statment are never
>> freed, but are properly freed for regular (good) sql statments.

>> This could very easily be a problem in my application code, but I
>> thought I'd ask if anyone had come accross this before.

>I vaguely recall having problems with ODBC (years ago).
>I can't recall the details, but they were solved by
>using updated ODBC drivers from the database vendor,
>instead of using the Microsoft supplied driver.
>--yanni



Sun, 17 Apr 2005 17:33:56 GMT  
 TopLink errors and memory leaks
Hi Mike,

We found the same problem a long time ago when we where using TOPLink, we fixed it by re-writing the error handler block to release the handles as happens when the SQL is sucessful.

Hope this helps
Ian

---------------------------
Posted via SST !



Mon, 18 Apr 2005 03:43:51 GMT  
 TopLink errors and memory leaks
Thanks to you both... Cycling the DB connection does in fact recover
the leaked memory, but it's a performance hit (and a hack).  I'd only
be cycling the connection after 1000 or so errors anyway, at that
point I'm not sure how much I care about performance!

Mike


Quote:
> Had the same problem with the Sybase driver a few years ago.  If you
> do an allInstances of the Error that is being generated I'm willing to
> bet that you will find that it is creating the Error over and over
> again.  In the case mentioned above, the error severity was pretty
> high and as far as I can remember, the only way to stop the errors
> from being created was to disconnect the connection, and create a new
> one.  This was fixed when we went to ODBC.  
> Good Luck
> Don Stacy



> >> I'm using TOPLink with VAST 55...  I've found a memory leak; it's not
> >> in the Smalltalk image, but rather it happens when TOPLink fails to
> >> free a statement handle on an error.  Have any of you run into this?
> >> The test I set up executes some bad SQL, the database returns an error
> >> which is in turn handled (ignored) by my app.  When the error is in a
> >> loop the memory climbs; taking a look at the ODBC trace shows that
> >> statement handles allocated for the (bad) sql statment are never
> >> freed, but are properly freed for regular (good) sql statments.

> >> This could very easily be a problem in my application code, but I
> >> thought I'd ask if anyone had come accross this before.

> >I vaguely recall having problems with ODBC (years ago).
> >I can't recall the details, but they were solved by
> >using updated ODBC drivers from the database vendor,
> >instead of using the Microsoft supplied driver.
> >--yanni



Mon, 18 Apr 2005 05:01:54 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Uninitialized memory errors and memory leaks in Tk

2. memory leak and leak-fixing 'patterns'

3. Any memory error/leak detection tools?

4. python startup memory size and memory leak

5. memory usage (how to debug a memory leak?)

6. Possible Dolphi R4 memory leak using ODBC

7. GETDSAB and memory leaks

8. How to pinpoint memory leaks

9. memory leak in gawk 3.1.0 ?

10. ENFIN Memory Leak

11. Memory Leaks

12. Memory Leaks in OS X?

 

 
Powered by phpBB® Forum Software