This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Memory / performance issues w/ db | ||
---|---|---|---|
Product: | db | Reporter: | _ tboudreau <tboudreau> |
Component: | Code | Assignee: | Libor Fischmeistr <lfischmeistr> |
Status: | RESOLVED INCOMPLETE | ||
Severity: | normal | CC: | pandajava |
Priority: | P3 | ||
Version: | 7.0 | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
_ tboudreau
2011-02-28 16:11:46 UTC
*** Bug 195392 has been marked as a duplicate of this bug. *** Closing this as INCOMPLETE. Of course it is possible to wrap every JDBC object into another wrapper, but I don't see it as a solution, but only as another possible point of failure. There are memory problems in db code of netbeans, but many (I'd bet most of them) are not caused by not properly closing/handling jdbc resources. You see a slow down in netbeans - I'd like to see a heapdump + threaddump of the problem. Please feel free to reopen this bug. If you read the detailed description I gave, two examples where this is a problem are clearly identified. And not closing statements and result sets is plainly a bug - it is not using these objects in the way that is clearly outlined in the JDBC spec - a heap dump wouldn't tell you anything that isn't obvious by glancing at the code. Reopening. "I don't feel like reading the code" does not make a bug incomplete. Simple diagnostic: Use a connection pool such as BoneCP that features unclosed resource tracking, and it will tell you when an unclosed JDBC resource gets garbage collection. You asume(!) jdbc resources are not properly closed. You claim unclosed JDBC objects hold resources that don't show up on heapdump but flood your heap. I seriously doubt that. I had another quick glance at the code - the statements are closed correctly (either try-with-resource of closed in finally block), ResultSets are closed - in an error condition they might end up unclosed, but then you'd have seen error messages. I understand your idea but as said it introduces another complexity layer without a proven problem. Just for the record - please keep you accusations for yourself - I'm far from reluctant to dig through the code, but without a lead it's just pointless. |