Hi,
to demonstrate the problem, i've written some code which approximates
the code i'm using. (attached)
I'm running Java 1.4.2 with the JVM parameter -Xmx64m.
If you run the test() method, the memory used by the JVM rises to
above 150mb until the following exception happens:
Mamta Satoor wrote:
Hi Paul,
Following is what Derby's Reference Guide says about IDENTITY_VAL_LOCAL
IDENTITY_VAL_LOCAL
Derby supports the IDENTITY_VAL_LOCAL function.
[...]
So I think the answer to Paul's question is not answered by that
documentation.
Does it mean the most recent
On Fri, 13 May 2005, Daniel John Debrunner wrote:
So I think the answer to Paul's question is not answered by that
documentation.
Right.
Does it mean the most recent INSERT for that connection or the most
recent insert to the database.
What about the most recent insert for a table? Does:
Does anyone know if it is expected in derby to accumulate memory in
a single transaction if you don't close statements or resultSets?
I am pretty sure not closing ResultSets is a problem, I am not sure
about Statements.
Daniel John Debrunner wrote:
Chris wrote:
Hi,
to demonstrate the problem,
On Fri, 13 May 2005, Mamta Satoor wrote:
The SELECT IDENTITY_VAL_LOCAL() FROM mytable1 will return the value that got
into generated for *any* table with identity column using single row insert
with values clause in the current transaction.
^^
Mamta Satoor wrote:
The SELECT IDENTITY_VAL_LOCAL() FROM mytable1 will return the value that
got into generated for _any_ table with identity column using single row
insert with values clause in the current transaction.
Except it doesn't behave like that, with respect to the *current
Hi,
I will file a doc JIRA entry for the IDENTITY_VAL_LOCAL() function, so there is the crucial *connection* dependency identified.
Also, I have added one more subtest to autoincrement.sql which tests the return value of this function for 2 different connections. Can someone commit the patch for
If you keep reusing Statement object, I don't believe there is a leak.
If one keeps creating a new Statement for every query executed, there
seems to be a leak. Derby client also behaves the same way as embedded
driver here.
Seems like a very bad practice...
Satheesh
Mike Matrigali wrote:
I noticed that PreparedStatement has a getGeneratedKeys()
method. I assume it's an alternate means of getting generated
key values that IDENTITY_VAL_LOCAL() would get. So I tried it.
However, getGeneratedKeys() returns null. I tried called
This is http://issues.apache.org/jira/browse/DERBY-201. Derby currently
has limitations getting auto generated columns.
Satheesh
Paul J. Lucas wrote:
I noticed that PreparedStatement has a getGeneratedKeys()
method. I assume it's an alternate means of getting generated
key
What does this return if the table has a trigger defined which inserts
into another table which also has an identity defined? Is it the value
from the statement's table or the one modified by the trigger?
I could not see where this is explictly defined in the docs. I have seen
this cause
Hi Paul,
org.apache.derbyTesting.functionTests.tests.jdbcap.autoGeneratedJdbc30.java class has a test (search for Test 6 in that class) and you will see that there is a positive test for PreparedStatement.getGeneratedKeys. Note that there is
Statement.RETURN_GENERATED_KEYS passed to the
12 matches
Mail list logo
