[jira] Created: (DERBY-3291) derbynet/testProperties.java fails with missing 'Log Connections changed to on.'
derbynet/testProperties.java fails with missing 'Log Connections changed to on.' Key: DERBY-3291 URL: https://issues.apache.org/jira/browse/DERBY-3291 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: OS: SUSE Linux Enterprise Server 10 (x86_64) [Version 10 / Patchlevel 10] 64bits - Linux 2.6.16.21-0.8-smp #1 SMP Mon Jul 3 18:25:39 UTC 2006 GNU/Linux JVM: Sun Microsystems Inc. 1.6.0_01-b06 Reporter: Ole Solberg Priority: Minor Seen only once - on svn rev. 605618. http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/testlog/sles/605618-derbyall_diff.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3292) ArrayIndexOutOfBoundsException: -1 in testBlobInTriggerTable(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)
ArrayIndexOutOfBoundsException: -1 in testBlobInTriggerTable(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest) -- Key: DERBY-3292 URL: https://issues.apache.org/jira/browse/DERBY-3292 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: OS: Microsoft(R) Windows(R) Server 2003, - 5.2.3790 Service Pack 2 - WindowsNT 2 5 JVM: Sun Microsystems Inc. 1.6.0-b105, Sun Microsystems Inc. 1.5.0_14-b03 Reporter: Ole Solberg Priority: Minor 1) testBlobInTriggerTable(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)java.lang.ArrayIndexOutOfBoundsException: -1 2) testUpdateTriggerOnClobColumn(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)java.sql.SQLException: Table/View 'T_LOB1_LOG' already exists in Schema 'APP'. Error 2) is a consequence of 1). See http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/testlog/w2003/605252-suitesAll_diff.txt , http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/testlog/w2003/605252-suitesAll_diff.txt . Seen only on svn rev. 605252, JVM 1.5 and 1.6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3282) Add a mechanism for managing users in Derby
[ https://issues.apache.org/jira/browse/DERBY-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553709 ] Øystein Grøvlen commented on DERBY-3282: I find it a bit difficult to relate to the concept system-wide users since I feel it is not very well defined what a Derby system actually is. Hence, I think we first need to step back even further and discuss the need for system-wide administration, in general. Why do we want system-wide administration? How will an administrator define a system and add databases to a system? What kind of properties should the databases of a system share? With the current flexibility where you are able to just copy a database to another location and keep on using it as before, it becomes very difficult to maintain information at system level. It also seems like it confuses many that users can be defined at two levels, system and database. I think the most important goal is to make Derby easy to get started with for new users. For that purpose, and for the purpose of single database administration, users at database level should suffice. However, the problem is that the current administration of built-in database users is awkward and different from what people are used to from other database systems. I think DERBY-866 shows how this situation can be improved. Then you have the minority of Derby users that administrates several databases and find it tedious (and maybe error-prone) to repeat the same administrative operations on all databases. They would probably like to have some tool that ease the administration of all databases of the system. A tool that let them create databases, add users at system level etc. It seems to me that the simplest would be to require that the only way to update information at system level is through this tool. To keep the current flexibility, if some of the system information is to affect a database, this tool will have to push the information into the database. For example, when a user is defined in this tool, the tool will create a built-in database level user in all the databases for which this user is to be known. While such a tool would be good to have, I feel it is much less important than to get a usable solution at database level. I also feel that it is pretty independent of what we do with respect to DERBY-866. > Add a mechanism for managing users in Derby > --- > > Key: DERBY-3282 > URL: https://issues.apache.org/jira/browse/DERBY-3282 > Project: Derby > Issue Type: Improvement > Components: Security >Reporter: Rick Hillegas > > Currently, managing users in Derby is awkward. The BUILTIN mechanism seems > appropriate for testing purposes, but has problems in a production setting. > DERBY-866 describes part of a new mechanism for managing users. DERBY-866 may > be part of the right solution--or it may not be. I think it would be > worthwhile to step back from this issue and first describe at a high level > what the customer experience should be. By introducing a new mechanism, we > have the opportunity to think through the complete experience of user > management. Here are my initial thoughts: > 1) This mechanism is mutually exclusive with the currently supported settings > of the derby.authentication.provider property. > 2) There should be a super user who has the power to create, view, and drop > users, including database owners. The design should let this super user > delegate these powers to other users. > 3) In the new mechanism it is sufficient that user credentials are > system-wide. > 4) Database owners should nevertheless have the power to state which > usernames can connect to their databases. DBOs should also have the power to > state who can shut down their databases. This mechanism should be extensible > to managing other database-specific powers which fall outside the SQL spec. > The design should let the DBO delegate these powers to other users. > 5) Users should be able to change their own credentials whenever they want. > 6) No password needed for this mechanism should be stored in plaintext > anywhere on the system. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3292) ArrayIndexOutOfBoundsException: -1 in testBlobInTriggerTable(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)
[ https://issues.apache.org/jira/browse/DERBY-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553710 ] A B commented on DERBY-3292: Could this be a duplicate of DERBY-3287? > ArrayIndexOutOfBoundsException: -1 in > testBlobInTriggerTable(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest) > -- > > Key: DERBY-3292 > URL: https://issues.apache.org/jira/browse/DERBY-3292 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.4.0.0 > Environment: OS: Microsoft(R) Windows(R) Server 2003, - 5.2.3790 > Service Pack 2 - WindowsNT 2 5 > JVM: Sun Microsystems Inc. 1.6.0-b105, Sun Microsystems Inc. 1.5.0_14-b03 >Reporter: Ole Solberg >Priority: Minor > > 1) > testBlobInTriggerTable(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)java.lang.ArrayIndexOutOfBoundsException: > -1 > 2) > testUpdateTriggerOnClobColumn(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)java.sql.SQLException: > Table/View 'T_LOB1_LOG' already exists in Schema 'APP'. > Error 2) is a consequence of 1). > See > http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/testlog/w2003/605252-suitesAll_diff.txt > , > http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/testlog/w2003/605252-suitesAll_diff.txt > . > Seen only on svn rev. 605252, JVM 1.5 and 1.6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
test* methods may get executed in a different order
I'm trying to get all the tests in suites.All to run successfully with the phoneME advanced platform. A problem I have discovered is that when JUnit creates a suite of tests from the test* methods in a class, I get them executed in a different order on this platform (seems to be the exact opposite order). I guess reflection behaves a little different, I don't think it's a bug. This causes some tests to fail because they are not really independent of the order that the test* methods in the class get executed, but the methods happen to be executed in an order that works when running on other JVMs. I don't think it's a huge issue, I don't know yet how many tests are failing because of this as there is still too much noise in my testresults, but I've discovered a few so far. I just wanted to mention it so that people are aware that the order the methods get executed in may be different in other environments, even though they normally get executed in the order they have in the file, so all the test* methods do have to work independent of the order. Vemund
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (8 issues) Subscriber: derby-dev Key Summary DERBY-3037 Language ResultSet.finish() is called even when the ResultSet is going to be re-used. https://issues.apache.org/jira/browse/DERBY-3037 DERBY-3278 Developer's Guide topic cdevdvlp51654 has duplicate information on connection URL https://issues.apache.org/jira/browse/DERBY-3278 DERBY-3117 Adjust master build script to require the Java 5 compiler to build Derby https://issues.apache.org/jira/browse/DERBY-3117 DERBY-3250 NetworkServerTestSetup will fail when starting the server as a process if any of the command line arguments contains a space https://issues.apache.org/jira/browse/DERBY-3250 DERBY-3023 Different result rows depending on the sequence of INNER JOIN and OUTER JOIN https://issues.apache.org/jira/browse/DERBY-3023 DERBY-2953 Dump the information about rollbacks of the global transaction (introduced in DERBY-2220 and DERBY-2432) to derby.log https://issues.apache.org/jira/browse/DERBY-2953 DERBY-3083 Network server demands a file called "derbynet.jar" in classpath https://issues.apache.org/jira/browse/DERBY-3083 DERBY-3227 Remove final from all getConnection() methods in EmbeddedDataSource https://issues.apache.org/jira/browse/DERBY-3227
Regression Test Report - Daily 605618 - Sun DBTG
[Auto-generated mail] *Daily* 605618/2007-12-19 18:00:12 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0272272 071.63% derbyall 01014610146 0 1274.39% suitesAll linN+1 0272272 0 .% derbyall 01014610146 0 .% suitesAll sles 1272271 072.46% derbyall 01014610146 0 879.18% suitesAll sol 0272272 075.90% derbyall NA NA NANA suitesAll solN+1 0272272 083.74% derbyall 01014610146 0 1391.17% suitesAll sparc 0272272 065.33% derbyall 01014610146 0 355.87% suitesAll vista 0272272 0 .% derbyall 091249124 0 415.85% suitesAll w2003 0272272 0 .% derbyall 091249124 0 240.61% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-605618.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/605618_bySig.html *Jvm: 1.5* lin 0273273 071.33% derbyall 084308430 0 881.55% suitesAll linN+1 0273273 0 .% derbyall 084308430 0 .% suitesAll sles 0273273 070.54% derbyall 084308430 0 566.08% suitesAll sol NA NA NANA derbyall NA NA NANA suitesAll solN+1 0273273 087.92% derbyall 084308430 0 786.88% suitesAll sparc 0273273 066.36% derbyall 084308430 0 688.97% suitesAll vista 0273273 071.57% derbyall 074087408 0 403.29% suitesAll w2003 0273273 073.72% derbyall 074087408 0 257.52% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-605618.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/605618_bySig.html *Jvm: 1.4* lin 0270270 272.72% derbyall 083788378 0 791.31% suitesAll linN+1 0270270 2 .% derbyall 083788378 0 .% suitesAll sles 0270270 269.68% derbyall 083788378 0 528.40% suitesAll sol NA NA NANA derbyall NA NA NANA suitesAll solN+1 0270270 288.51% derbyall 083788378 0 824.14% suitesAll sparc 0270270 266.69% derbyall 083788378 0 696.52% suitesAll vista 0270270 2 .% derbyall 073567356 0 385.76% suitesAll w2003 0270270 2 .% derbyall 073577357 0 .% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-605618.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/605618_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/605618.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Re: test* methods may get executed in a different order
Vemund Ostgaard wrote: I'm trying to get all the tests in suites.All to run successfully with the phoneME advanced platform. A problem I have discovered is that when JUnit creates a suite of tests from the test* methods in a class, I get them executed in a different order on this platform (seems to be the exact opposite order). I guess reflection behaves a little different, I don't think it's a bug. This causes some tests to fail because they are not really independent of the order that the test* methods in the class get executed, but the methods happen to be executed in an order that works when running on other JVMs. I don't think it's a huge issue, I don't know yet how many tests are failing because of this as there is still too much noise in my testresults, but I've discovered a few so far. I just wanted to mention it so that people are aware that the order the methods get executed in may be different in other environments, even though they normally get executed in the order they have in the file, so all the test* methods do have to work independent of the order. Vemund Thanks for bringing this up, Vemund. I think that the JUnit documentation states that the order in which test* tests run is not guaranteed to be same across platforms--unless you hardcode the order you want by explicitly adding each test* test to your suite. Regards, -Rick
Re: test* methods may get executed in a different order
Vemund Ostgaard wrote: I'm trying to get all the tests in suites.All to run successfully with the phoneME advanced platform. A problem I have discovered is that when JUnit creates a suite of tests from the test* methods in a class, I get them executed in a different order on this platform Thanks for the reminder Vemund, I thought this was on the Derby junit wiki pages but I couldn't find it so I added information in: http://wiki.apache.org/db-derby/DerbyJunitTestConfiguration Dan.
[jira] Commented: (DERBY-3282) Add a mechanism for managing users in Derby
[ https://issues.apache.org/jira/browse/DERBY-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553739 ] Rick Hillegas commented on DERBY-3282: -- Thanks for continuing the conversation about this topic, Øystein. Yes indeed, let's step further back! I agree that the definition of a Derby system is not what you might want. In practical terms it is something like this: the set of Derby resources managed by a single VM relying on a single set of system properties and a single master property file. It is not a set of Derby databases, which might be what you want. Multiple Derby systems could run on a single machine and, in the worst case, a given database could drift back and forth between two systems, depending on which system touches it first after a reboot. I understand the appeal of moving databases from one location to another, maybe even between Derby systems. I think that this is particularly appealing for single-user, shrink-wrapped applications. However, there are already limitations on this useful feature. For instance, important aspects of a database's behavior may be governed by the master property file and this does not live in the database's directory. In addition, a database is sensitive to the version of Derby which created it. You can't move a 10.3 database into a Derby system which is running 10.2. In order to move databases safely, you may also have to move some of the "system" context. Unfortunately, some authentication is already part of this "system" context. That is because you need system-wide credentials in order to create databases and bring down the "system". It seems awkward to me that you technically need one set of credentials in order to perform these system tasks and another set of credentials in order to perform work in a database. In practice, I seriously doubt that there are many (or even any) Derby applications which use different credentials for system-wide vs. database-specific tasks. Good evidence for this is provided I think by the fact that no production user has tripped across DERBY-3271 yet. In fact, the system-wide credentials which you use to create a database MUST BE the very same database-specific credentials which you use to do work in the database, at least initially. This is because database creation actually involves two authentication passes. In the first pass, you authenticate at the system level in order to create the system tables on disk. In the second pass, you then authenticate (using the same credentials) at the database level in order to get a connection to the newly created database. I don't believe that this coupling of the two credential schemes is documented anywhere. It is an unwritten assumption about the way that Derby authentication behaves. I think it would be confusing and awkward to require customers to operate two different mechanisms for administering users: one mechanism for administering users at the system level and another mechanism for administering users at the database level. For the record, I don't have any quarrel with the syntax described in DERBY-866. I do have reservations about the database-specific scope of the syntax and about the requirement that system-wide credentials be stored in the master property file. > Add a mechanism for managing users in Derby > --- > > Key: DERBY-3282 > URL: https://issues.apache.org/jira/browse/DERBY-3282 > Project: Derby > Issue Type: Improvement > Components: Security >Reporter: Rick Hillegas > > Currently, managing users in Derby is awkward. The BUILTIN mechanism seems > appropriate for testing purposes, but has problems in a production setting. > DERBY-866 describes part of a new mechanism for managing users. DERBY-866 may > be part of the right solution--or it may not be. I think it would be > worthwhile to step back from this issue and first describe at a high level > what the customer experience should be. By introducing a new mechanism, we > have the opportunity to think through the complete experience of user > management. Here are my initial thoughts: > 1) This mechanism is mutually exclusive with the currently supported settings > of the derby.authentication.provider property. > 2) There should be a super user who has the power to create, view, and drop > users, including database owners. The design should let this super user > delegate these powers to other users. > 3) In the new mechanism it is sufficient that user credentials are > system-wide. > 4) Database owners should nevertheless have the power to state which > usernames can connect to their databases. DBOs should also have the power to > state who can shut down their databases. This mechanism should be extensible > to managing other database-specific powers which fall outside
How to create a ContainerHandle from a given LogRecord
Hello!
I've been studying derby's logging system. I want to parse the log files
on disk extract its LogRecord(s) and write those
to an arbitrary stream to do some post-processing latter on.
I am using LogFactory.openForwardsScan() to traverse the log between the
desired LogInstant(s).
This works well except for the log records on the group
Loggable.RAWSTORE (and ContainerOperation instances in particular).
The problem is that when I try to invoke writeExternal on LogRecords of
that group I get an NPE because
some fields of the Loggable are null (due to being transient and hence
not saved to disk).
I will try to explain better with a small code snippet:
//
void parseLog(){
StreamLogScan redoScan;
try {
LogInstant a = ...
LogInstant b = ...
//go from LogInstant 'a' to 'b'
redoScan = (StreamLogScan) logFactory.openForwardsScan(a,b);
LogRecord record;
while ((record = redoScan.getNextRecord(logIn, null, 0))
!= null) {
writeLog(record.getTransactionId(),record.getLoggable(),redoScan.getInstant());
}
return ;
}
//write the LogRecord to a stream ...
void writeLog(TransactionId transactionId,Loggable operation, long
instant) throws IOException, StandardException {
DynamicByteArrayOutputStream logOutputBuffer = new
DynamicByteArrayOutputStream(1024);
FormatIdOutputStream logicalOut = new
FormatIdOutputStream(logOutputBuffer);
ArrayInputStream logIn = new ArrayInputStream();
LogRecord logRecord = new LogRecord();
logRecord.setValue(transactionId, operation);
//ERROR here when logrecord group is Loggable.RAWSTORE
logicalOut.writeObject(logRecord);
byte[] data = logOutputBuffer.getByteArray();
//do something with the data ...
}
//
Let's focus on the particular case that the LogRecord's Loggable is a
ContainerOperation.
The line "logicalOut.writeObject(logRecord)" eventually invokes
ContainerOperation.writeExternal() and because that object
is not correctly instantiated it throws an NPE when trying to access the
RawContainerHandle containerHdl.
I think that I must create a ContainerOperation object with an adequate
RawContainerHandle
but I am unable to do it from the information contained _only_ in the
LogRecord.
I have been playing around with RawStoreFactory and TransactionFactory
but without any success.
What am I missing ? Is my reasoning correct ? And if so how can I solve
this problem?
Thanks for you time.
Miguel
smime.p7s
Description: S/MIME Cryptographic Signature
[jira] Closed: (DERBY-3292) ArrayIndexOutOfBoundsException: -1 in testBlobInTriggerTable(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)
[ https://issues.apache.org/jira/browse/DERBY-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Solberg closed DERBY-3292. -- Resolution: Duplicate Stacktrace (insane) indicates this is a duplicate of DERBY-3287, so closing as such. > ArrayIndexOutOfBoundsException: -1 in > testBlobInTriggerTable(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest) > -- > > Key: DERBY-3292 > URL: https://issues.apache.org/jira/browse/DERBY-3292 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.4.0.0 > Environment: OS: Microsoft(R) Windows(R) Server 2003, - 5.2.3790 > Service Pack 2 - WindowsNT 2 5 > JVM: Sun Microsystems Inc. 1.6.0-b105, Sun Microsystems Inc. 1.5.0_14-b03 >Reporter: Ole Solberg >Priority: Minor > > 1) > testBlobInTriggerTable(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)java.lang.ArrayIndexOutOfBoundsException: > -1 > 2) > testUpdateTriggerOnClobColumn(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)java.sql.SQLException: > Table/View 'T_LOB1_LOG' already exists in Schema 'APP'. > Error 2) is a consequence of 1). > See > http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/testlog/w2003/605252-suitesAll_diff.txt > , > http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/testlog/w2003/605252-suitesAll_diff.txt > . > Seen only on svn rev. 605252, JVM 1.5 and 1.6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: File Permission for ij tests
Thanks Dan. But still I'm getting the same error. I changed the code like
this
public void testDataPopulation() throws SQLException {
String[] dbfiles = {"ToursDB_schema.sql","loadTables.sql"};
BufferedInputStream inStream;
// Connection conn = getConnection();
try{
for (int i = 0 ; i < dbfiles.length ; i++)
{
inStream = new BufferedInputStream(new
FileInputStream(dbfiles[i]),
utilMain.BUFFEREDFILESIZE);
runScript(inStream, "US-ASCII");
}
} catch (Exception e) {
fail("Unexpected while populating the data" + e.getMessage
());
}
}
Still getting the same Exception.
-Manjula
On 12/19/07, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
>
> Manjula Kutty wrote:
> > Hi,
> >
> > I was trying to convert the test demo/checkToursDB.java to junit and I
> > came throug this error. Does any one know how to resolve this issue?
>
> BaseJDBCTestCase has utility methods to run sql scripts, see the
> runScript methods in the class.
>
> Dan.
>
--
Thanks,
Manjula.
Re: File Permission for ij tests
Manjula Kutty wrote:
Thanks Dan. But still I'm getting the same error.
Can you use the other runScript method?
E.g. something like:
runScript("org/apache/derbyTesting/", "US-ASCII");
This works for script files that are in derbyTesting.jar or the classpath.
Dan.
[jira] Commented: (DERBY-3037) Language ResultSet.finish() is called even when the ResultSet is going to be re-used.
[ https://issues.apache.org/jira/browse/DERBY-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553877 ] Mamta A. Satoor commented on DERBY-3037: ommited the patch Derby_3037_AlterTableConstantActionChanges_v1_diff.txt with revision 606106 into trunk. Will merge into 10.3 later. > Language ResultSet.finish() is called even when the ResultSet is going to be > re-used. > - > > Key: DERBY-3037 > URL: https://issues.apache.org/jira/browse/DERBY-3037 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Daniel John Debrunner >Assignee: Mamta A. Satoor > Fix For: 10.3.2.2, 10.4.0.0 > > Attachments: Derby_3037_AlterTableConstantActionChanges_v1_diff.txt, > Derby_3037_AlterTableConstantActionChanges_v1_stat.txt > > > DERBY-827 (correctly) changed the lifetime of the language ResultSet tree to > be the lifetime of the activation, but did not fix up the correct calls to > ResultSet.close() and ResultSet.finish(). > A language ResultSet's lifetime should be driven by the activation, so > activation.close() should call finish() on its ResultSet. > EmbedResultSet should call close on its language ResultSet (theResults field) > when the JDBC ResultSet is closed, it should not be calling finish() on its > ResultSet. > See comments in DERBY-827 for some more details and issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-3037) Language ResultSet.finish() is called even when the ResultSet is going to be re-used.
[ https://issues.apache.org/jira/browse/DERBY-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553877 ] mamtas edited comment on DERBY-3037 at 12/20/07 10:54 PM: --- Commited the patch Derby_3037_AlterTableConstantActionChanges_v1_diff.txt with revision 606106 into trunk. Will merge into 10.3 later. was (Author: mamtas): ommited the patch Derby_3037_AlterTableConstantActionChanges_v1_diff.txt with revision 606106 into trunk. Will merge into 10.3 later. > Language ResultSet.finish() is called even when the ResultSet is going to be > re-used. > - > > Key: DERBY-3037 > URL: https://issues.apache.org/jira/browse/DERBY-3037 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Daniel John Debrunner >Assignee: Mamta A. Satoor > Fix For: 10.3.2.2, 10.4.0.0 > > Attachments: Derby_3037_AlterTableConstantActionChanges_v1_diff.txt, > Derby_3037_AlterTableConstantActionChanges_v1_stat.txt > > > DERBY-827 (correctly) changed the lifetime of the language ResultSet tree to > be the lifetime of the activation, but did not fix up the correct calls to > ResultSet.close() and ResultSet.finish(). > A language ResultSet's lifetime should be driven by the activation, so > activation.close() should call finish() on its ResultSet. > EmbedResultSet should call close on its language ResultSet (theResults field) > when the JDBC ResultSet is closed, it should not be calling finish() on its > ResultSet. > See comments in DERBY-827 for some more details and issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
