Craig L Russell wrote:
[snip]
Again, I want to say that I came into this discussion late, and was
originally under the impression that you had an application that you
were looking to optimize. I apologize if my comments took everyone off
track.
Yes, I was a bit worried that the length of
[EMAIL PROTECTED] wrote:
[snip]
So the better question is... do you blame the hammer or the carpenter
when he
can't hit a nail straight in to the wood?
Who to blame is IMHO not the most important thing if the house falls
down on the person who lives there because of this.
[mjs]
Again
On Feb 1, 2006, at 8:06 AM, John Embretsen wrote:
Craig L Russell wrote:
If this test code is representative of the actual application,
then the application is in trouble and should be reimplemented in
the jdbc area. It is a very well-understood requirement of well-
behaved application
Craig L Russell wrote:
If this test code is representative of the actual application, then the
application is in trouble and should be reimplemented in the jdbc area.
It is a very well-understood requirement of well-behaved applications
that result sets and prepared statements and connectio
> -Original Message-
> From: John Embretsen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 01, 2006 9:12 AM
> To: Derby Discussion
> Subject: Re: OutOfMemoryErrors when testing Derby with DOTS
>
> Michael Segel wrote:
>
> > I think that there
Michael Segel wrote:
I think that there are two issues. One how Derby handles itself and attempts
to clean up stale objects.
The second is that whoever wrote the test didn't know what they were doing.
So that question is: "Should Derby be smart enough to protect bad programmers
from themselve
Craig L Russell wrote:
>> Daniel John Debrunner wrote:
>> If it no longer has a reference to a open JDBC open then it is no longer
>> using it and Derby must allow it to be garbage collected and release any
>> of its resources during its garbage collection.
>
>
> This is possible but can be t
Hi Dan,
On Jan 31, 2006, at 12:04 PM, Daniel John Debrunner wrote:
Daniel John Debrunner wrote:
There's no guessing, if the application has a reference to an open
JDBC
object then it is still using it. If it no longer has a reference
to a
open JDBC open then it is no longer using it and
> Craig L Russell wrote:
>
>
>> Long term, I don't believe that Derby or any other implementation
>> should try to optimize for applications written without regard for good
>> programming patterns.
>
> In this case Derby needs to follow the JDBC spec and correctly handle
> garbage collected JDBC o
Daniel John Debrunner wrote:
> There's no guessing, if the application has a reference to an open JDBC
> object then it is still using it. If it no longer has a reference to a
> open JDBC open then it is no longer using it and Derby must garbage
> collect it.
I could have worded that last bit be
Craig L Russell wrote:
> Long term, I don't believe that Derby or any other implementation
> should try to optimize for applications written without regard for good
> programming patterns.
In this case Derby needs to follow the JDBC spec and correctly handle
garbage collected JDBC objects. I d
Hi John,
On Jan 31, 2006, at 9:14 AM, John Embretsen wrote:
Tuesday, January 31, 2006, 3:03:38 AM CET, Craig L Russell wrote:
Hi John,
On Jan 30, 2006, at 12:11 PM, John Embretsen wrote:
[snip old quotes]
Any reason why itemID is bound to the preparedStatement and not
itself passed as
On Tuesday 31 January 2006 11:14 am, John Embretsen wrote:
> Personally, I would prefer a database with a strong enough helmet to
> withstand such hammer hits. Someone else may find that hammer one
> day, and hit you again ;)
I think that there are two issues. One how Derby handles itself and att
Tuesday, January 31, 2006, 3:03:38 AM CET, Craig L Russell wrote:
> Hi John,
> On Jan 30, 2006, at 12:11 PM, John Embretsen wrote:
[snip old quotes]
>>> Any reason why itemID is bound to the preparedStatement and not
>>> itself passed as a parameter?
>>
>>> Generally, preparing statements like
Hi John,
On Jan 30, 2006, at 12:11 PM, John Embretsen wrote:
Monday, January 30, 2006, 7:46:42 PM, Craig L Russell wrote:
Hi,
On Jan 27, 2006, at 4:11 PM, Ramandeep Kaur wrote:
Hi,
As per Stan's mail about prepared statements, I checked the source
code for DOTS test case that John ran
[SNIP]
> > Any reason why itemID is bound to the preparedStatement and not
> > itself passed as a parameter?
>
> > Generally, preparing statements like this (those that include
> > parameters) just before use has little benefit. The big win is to
> > prepare the statement and then reuse it every
Monday, January 30, 2006, 7:16:04 PM, [EMAIL PROTECTED] wrote:
> Uhm...
> Silly question. Why so many prepared statements?
I don't know. See my reply to Craig's message:
http://mail-archives.apache.org/mod_mbox/db-derby-user/200601.mbox/[EMAIL
PROTECTED]
--
John
Monday, January 30, 2006, 7:46:42 PM, Craig L Russell wrote:
> Hi,
> On Jan 27, 2006, at 4:11 PM, Ramandeep Kaur wrote:
>> Hi,
>>
>> As per Stan's mail about prepared statements, I checked the source
>> code for DOTS test case that John ran (ATCJ2.java) to see if
>> prepared statements are g
Hi,On Jan 27, 2006, at 4:11 PM, Ramandeep Kaur wrote:Hi, As per Stan's mail about prepared statements, I checked the source code for DOTS test case that John ran (ATCJ2.java) to see if prepared statements are getting closed properly. I found that there are few methods in ATCJ2.java where prepared
Uhm...
Silly question. Why so many prepared statements?
-Original Message-
From: John Embretsen [mailto:[EMAIL PROTECTED]
Sent: Monday, January 30, 2006 4:13 AM
To: Derby Discussion
Subject: Re: OutOfMemoryErrors when testing Derby with DOTS
Saturday, January 28, 2006, 1:11:31 AM CET
yes, that is correct. When I ran DOTS tests, I noticed that increasing heap size just increased the time when Network Server JVM ran out of memory (for example: from 2 days to 5 days). So actual solution would be fix memory leak.
-- Ramandeep Kaur[EMAIL PROTECTED]
On 1/30/06, John Embretsen <[EM
Saturday, January 28, 2006, 1:11:31 AM CET, Ramandeep Kaur wrote:
> Hi,
>
> As per Stan's mail about prepared statements, I checked the source
> code for DOTS test case that John ran (ATCJ2.java) to see if prepared
> statements are getting closed properly. I found that there are
> few methods
Hi,
As per Stan's mail about prepared statements, I checked the source code for DOTS test case that John ran (ATCJ2.java) to see if prepared statements are getting closed properly. I found that there are few methods in
ATCJ2.java where prepared statements are not getting closed.
The following
On 1/27/06, John Embretsen <[EMAIL PROTECTED]> wrote:
> Friday, January 27, 2006, 6:14:12 PM, Deepa Remesh wrote:
>
> > Hi John,
>
> > After a quick read of your mail, it seems to me some of the
> > OutOfMemoryErrors you are seeing may be because of the leak described
> > in DERBY-210. I have a pat
Deepa Remesh wrote:
Hi John,
After a quick read of your mail, it seems to me some of the
OutOfMemoryErrors you are seeing may be because of the leak described
in DERBY-210. I have a patch for this attached to the JIRA issue. If
it is okay, can you please try re-running the tests after applying
Friday, January 27, 2006, 6:14:12 PM, Deepa Remesh wrote:
> Hi John,
> After a quick read of your mail, it seems to me some of the
> OutOfMemoryErrors you are seeing may be because of the leak described
> in DERBY-210. I have a patch for this attached to the JIRA issue. If
> it is okay, can you p
Hi John,
After a quick read of your mail, it seems to me some of the
OutOfMemoryErrors you are seeing may be because of the leak described
in DERBY-210. I have a patch for this attached to the JIRA issue. If
it is okay, can you please try re-running the tests after applying
this patch? I think it
27 matches
Mail list logo
