Re: [VOTE] Dag Wanvik as a committer

+1 Regards Andreas

Re: [VOTE] Kristian Waagan as a committer

+1Regards Andreas

Re: [VOTE] Fernanda Pizzorno as a Derby committer

+1--Andreas

Re: [VOTE] Army Brown as a committer

+1Andreas

[jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

[ http://issues.apache.org/jira/browse/DERBY-1696?page=all ] Andreas Korneliussen updated DERBY-1696: Assignee: (was: Andreas Korneliussen) transaction may sometimes keep lock on a row after moving off the resultset in scrollable

[jira] Commented: (DERBY-1846) Create a script that allows users to easily update their Derby jars with the JDBC4 classes.

[ http://issues.apache.org/jira/browse/DERBY-1846?page=comments#action_12436798 ] Andreas Korneliussen commented on DERBY-1846: - I have successfully used this script now on solarisx86. My previous test was from the 10.2 branch

[jira] Updated: (DERBY-1862) Simple hash improves performance

[ http://issues.apache.org/jira/browse/DERBY-1862?page=all ] Andreas Korneliussen updated DERBY-1862: Attachment: DERBY-1862v3.diff Attaching a modified patch where I have taken in the advice of not creating the map object in the constructor

[jira] Closed: (DERBY-1564) wisconsin.java test failed in DerbyNet or DerbyNetClient frameworks, VM for network server got OutOfMemoryError

[ http://issues.apache.org/jira/browse/DERBY-1564?page=all ] Andreas Korneliussen closed DERBY-1564. --- Thanks for resolving this issue, I agree it can be closed. wisconsin.java test failed in DerbyNet or DerbyNetClient frameworks, VM for network

[jira] Commented: (DERBY-1846) Create a script that allows users to easily update their Derby jars with the JDBC4 classes.

[ http://issues.apache.org/jira/browse/DERBY-1846?page=comments#action_12436565 ] Andreas Korneliussen commented on DERBY-1846: - I think the script update-with-jdbc4 as it is now in SVN has a dangling-else problem if JAVA_HOME

[jira] Updated: (DERBY-1862) Simple hash improves performance

[ http://issues.apache.org/jira/browse/DERBY-1862?page=all ] Andreas Korneliussen updated DERBY-1862: Attachment: DERBY-1696v2.diff The attached patch makes a map of column names to column number. The map is populated when the first call

[jira] Updated: (DERBY-1862) Simple hash improves performance

[ http://issues.apache.org/jira/browse/DERBY-1862?page=all ] Andreas Korneliussen updated DERBY-1862: Attachment: DERBY-1862v2.diff Attached incorrect patch (DERBY-1696v2.diff). The correct patch is DERBY-1862v2.diff. Simple hash improves

Re: [jira] Updated: (DERBY-1862) Simple hash improves performance

Daniel John Debrunner wrote: Andreas Korneliussen wrote: Øystein Grøvlen wrote: Andreas Korneliussen (JIRA) wrote: String.toUpperCase(..) with english locale, should return a string with the same number of characters, and it should therefore be valid to do a check of number

Re: [jira] Updated: (DERBY-1862) Simple hash improves performance

As far as I remember from my high-school German, is that even if all ß may be converted to uppercase SS, not all SS in uppercase may be converted to the lowercase ß. If the SS appears in a combined word (in German, words are combined by concatenating them, as in Norwegian) where one

[jira] Updated: (DERBY-1862) Simple hash improves performance

[ http://issues.apache.org/jira/browse/DERBY-1862?page=all ] Andreas Korneliussen updated DERBY-1862: Attachment: DERBY-1862.diff Attached is a patch which uses another approach to improve the SQLEqualsIgnoreCase method. The patch check

[jira] Commented: (DERBY-1177) updateObject with null as argument causes network driver to fail with NullPointerException

[ http://issues.apache.org/jira/browse/DERBY-1177?page=comments#action_12435486 ] Andreas Korneliussen commented on DERBY-1177: - REL NOTE: Problem 1: The derby client driver throws an exception when calling ResultSet.updateObject

Re: [jira] Updated: (DERBY-1862) Simple hash improves performance

Øystein Grøvlen wrote: Andreas Korneliussen (JIRA) wrote: String.toUpperCase(..) with english locale, should return a string with the same number of characters, and it should therefore be valid to do a check of number of characters before doing any conversions. Is it correct to always use

[jira] Commented: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

[ http://issues.apache.org/jira/browse/DERBY-1696?page=comments#action_12435207 ] Andreas Korneliussen commented on DERBY-1696: - I will update the patch for this issue once the DERBY-1799 is reviewed and committed, since

[jira] Commented: (DERBY-1659) Document describe and show tables functionality

[ http://issues.apache.org/jira/browse/DERBY-1659?page=comments#action_12434702 ] Andreas Korneliussen commented on DERBY-1659: - I have just a minor comment on the doc: I have been testing this feature, and found that descrbie also

[jira] Commented: (DERBY-1691) jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6

[ http://issues.apache.org/jira/browse/DERBY-1691?page=comments#action_12433805 ] Andreas Korneliussen commented on DERBY-1691: - Patch looks good. Got one conflict in DerbyNet.exclude, which I resolved. I will run some tests

[jira] Resolved: (DERBY-1691) jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6

[ http://issues.apache.org/jira/browse/DERBY-1691?page=all ] Andreas Korneliussen resolved DERBY-1691. - Resolution: Fixed Committed revision 442199. jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6

Re: jdk1.6 regresstion test failures: _Suite.junit and TestQueryObject with IllegalAccessException

.. * Diff file derbyall/derbynetclientmats/DerbyNetClient/jdbc40/_Suite.diff *** Start: _Suite jdk1.6.0-rc DerbyNetClient derbynetclientmats:jdbc40 2006-09-01 21:27:16 *** 0 add F. There was 1 failure: 1)

[jira] Updated: (DERBY-1800) testSetBinaryStreamLengthLessOnBlobTooLong fails with 'Unexpected SQL state. expected:22001 but was:58009'

[ http://issues.apache.org/jira/browse/DERBY-1800?page=all ] Andreas Korneliussen updated DERBY-1800: Attachment: DERBY-1800.diff The problem is caused by not flushing the blob data after an exception occurs. Attached patch makes the test pass

[jira] Resolved: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen resolved DERBY-1559. - Fix Version/s: 10.2.2.0 Resolution: Fixed when receiving a single EXTDTA object representing a BLOB, the server do not need to read

[jira] Closed: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen closed DERBY-1559. --- when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

[ http://issues.apache.org/jira/browse/DERBY-1696?page=all ] Andreas Korneliussen updated DERBY-1696: Attachment: DERBY-1696v2.diff The attached patch also releases the lock on indexed scans. Additionally extended tests. transaction may

[jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

[ http://issues.apache.org/jira/browse/DERBY-1696?page=all ] Andreas Korneliussen updated DERBY-1696: Derby Info: (was: [Patch Available]) Removing patch available flag, since the second patch makes SURQueryMixTest fail. transaction may

[jira] Commented: (DERBY-1800) testSetBinaryStreamLengthLessOnBlobTooLong fails with 'Unexpected SQL state. expected:22001 but was:58009'

[ http://issues.apache.org/jira/browse/DERBY-1800?page=comments#action_12432508 ] Andreas Korneliussen commented on DERBY-1800: - Tests shows that the failure has been fixed. Derbyall passes. Running the jdbc40 suite, fails with more

[jira] Updated: (DERBY-1800) testSetBinaryStreamLengthLessOnBlobTooLong fails with 'Unexpected SQL state. expected:22001 but was:58009'

[ http://issues.apache.org/jira/browse/DERBY-1800?page=all ] Andreas Korneliussen updated DERBY-1800: Component/s: Network Server testSetBinaryStreamLengthLessOnBlobTooLong fails with 'Unexpected SQL state. expected:22001 but was:58009

[jira] Resolved: (DERBY-1800) testSetBinaryStreamLengthLessOnBlobTooLong fails with 'Unexpected SQL state. expected:22001 but was:58009'

[ http://issues.apache.org/jira/browse/DERBY-1800?page=all ] Andreas Korneliussen resolved DERBY-1800. - Fix Version/s: 10.3.0.0 Resolution: Fixed Committed revision 440062. testSetBinaryStreamLengthLessOnBlobTooLong fails

[jira] Created: (DERBY-1799) SUR: current row not locked when renavigating to it, in queries with indexes

Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0, 10.2.2.0, 10.3.0.0 Reporter: Andreas Korneliussen This problem is detected in transactions with isolation level read-committed/read-uncommitted. We have a table (T) which has a primary key (a), and a query which

[jira] Commented: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

[ http://issues.apache.org/jira/browse/DERBY-1696?page=comments#action_12432096 ] Andreas Korneliussen commented on DERBY-1696: - Thanks. Testing better with indexes also uncovered another locking issue w.r.t SUR : DERBY-1799. I

[jira] Assigned: (DERBY-1800) testSetBinaryStreamLengthLessOnBlobTooLong fails with 'Unexpected SQL state. expected:22001 but was:58009'

[ http://issues.apache.org/jira/browse/DERBY-1800?page=all ] Andreas Korneliussen reassigned DERBY-1800: --- Assignee: Andreas Korneliussen testSetBinaryStreamLengthLessOnBlobTooLong fails with 'Unexpected SQL state. expected:22001

[jira] Commented: (DERBY-1800) testSetBinaryStreamLengthLessOnBlobTooLong fails with 'Unexpected SQL state. expected:22001 but was:58009'

[ http://issues.apache.org/jira/browse/DERBY-1800?page=comments#action_12432140 ] Andreas Korneliussen commented on DERBY-1800: - I will check if this is caused by DERBY-1559, and if that is the case, fix the issue

[jira] Updated: (DERBY-1740) Change error message to indicate encryptionkey length to be atleast 16 characters instead of 8 characters

[ http://issues.apache.org/jira/browse/DERBY-1740?page=all ] Andreas Korneliussen updated DERBY-1740: Urgency: (was: Urgent) Unsetting the urgency flag. I think the urgency should be set to normal, as it is a matter of incorrect error message

[jira] Updated: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen updated DERBY-1559: Fix Version/s: 10.3.0.0 Derby Info: (was: [Patch Available]) Committed revision 438478 at trunk. when receiving a single EXTDTA

[jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

[ http://issues.apache.org/jira/browse/DERBY-1696?page=all ] Andreas Korneliussen updated DERBY-1696: Derby Info: [Patch Available] transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

[jira] Commented: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=comments#action_12431227 ] Andreas Korneliussen commented on DERBY-1559: - Thanks for the review. I will run some tests, and then commit the patch on the trunk. when receiving

[jira] Updated: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen updated DERBY-1559: Attachment: DERBY-1559v6.diff Found a bug while testing the patch DERBY-1559v5.diff: In case of an DRDAProtoclException while doing

Re: [jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

to beforeFirst / afterLast, this does not hold, and the flag must also be set in these cases as well. Andreas /mikem Andreas Korneliussen wrote: Can you just close the scan if you don't need it positioned anymore? I'll check if that works The problem is that we need it re-positioned later

[jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

[ http://issues.apache.org/jira/browse/DERBY-1696?page=all ] Andreas Korneliussen updated DERBY-1696: Attachment: DERBY-1696.diff DERBY-1696.stat The attached patch addresses this bug by having the SQL-execution layer use

[jira] Updated: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen updated DERBY-1559: Attachment: DERBY-1559v5.diff Attached patch makes DDMReader handle the DRDAProtocolException, and throws IOException from it, instead

Re: [jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

Mike Matrigali wrote: Andreas Korneliussen (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1696?page=all ] Andreas Korneliussen updated DERBY-1696: Component/s: Store To fix this issue, I need a mechanism to notify the store

Re: [jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

Can you just close the scan if you don't need it positioned anymore? I'll check if that works The problem is that we need it re-positioned later, i.e if the user moves to the afterLast() position and then scrolls to any other row, we need to lock that row. If the scan has been closed with

[jira] Assigned: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

[ http://issues.apache.org/jira/browse/DERBY-1696?page=all ] Andreas Korneliussen reassigned DERBY-1696: --- Assignee: Andreas Korneliussen transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable

[jira] Commented: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=comments#action_12430519 ] Andreas Korneliussen commented on DERBY-1559: - One last thought, then: does it make any sense to have DDMReader.readLobContinuationString throw

[jira] Updated: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen updated DERBY-1559: Attachment: DERBY-1559v4.diff Thanks for reviewing the patch. Attached is a patch where I try to address the issue w.r.t preserving

[jira] Updated: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen updated DERBY-1559: Attachment: DERBY-1559v3.diff Attached is an updated patch were the conflicts from DERBY-1610 has been resolved. Additionally, to avoid

Re: Question on SUR and U lock.

Sunitha Kambhampati wrote: I was doing some testing for SUR and had a question about the expected behavior. The SUR related doc on http://db.apache.org/derby/docs/dev/devguide/rdevconceptssur.html says The row which the cursor is positioned on is locked, however once it moves to another

[jira] Commented: (DERBY-1558) enable more testcases in ConcurrencyTest

[ http://issues.apache.org/jira/browse/DERBY-1558?page=comments#action_12429682 ] Andreas Korneliussen commented on DERBY-1558: - Committed revision 433607. enable more testcases in ConcurrencyTest

[jira] Resolved: (DERBY-1558) enable more testcases in ConcurrencyTest

[ http://issues.apache.org/jira/browse/DERBY-1558?page=all ] Andreas Korneliussen resolved DERBY-1558. - Resolution: Fixed enable more testcases in ConcurrencyTest Key: DERBY-1558

[jira] Closed: (DERBY-1558) enable more testcases in ConcurrencyTest

[ http://issues.apache.org/jira/browse/DERBY-1558?page=all ] Andreas Korneliussen closed DERBY-1558. --- enable more testcases in ConcurrencyTest Key: DERBY-1558 URL: http

Re: [junit] Move JUnit base/utility classes???

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kristian Waagan wrote: Hi, I still have a question regarding the placement of JUnit tests. I have brought this up before, but got very little response (I did get some, see below). Do we want to support [unit] testing of package private

[jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode

[ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429361 ] Andreas Korneliussen commented on DERBY-418: I think that the lack of synchronization when calling singleUseActivation.markUnused() may cause

[jira] Resolved: (DERBY-1712) Add a JUnit test decorator that starts the NetworkServer at setUp and stops it at tearDown.

[ http://issues.apache.org/jira/browse/DERBY-1712?page=all ] Andreas Korneliussen resolved DERBY-1712. - Resolution: Fixed Add a JUnit test decorator that starts the NetworkServer at setUp and stops it at tearDown

[jira] Closed: (DERBY-1712) Add a JUnit test decorator that starts the NetworkServer at setUp and stops it at tearDown.

[ http://issues.apache.org/jira/browse/DERBY-1712?page=all ] Andreas Korneliussen closed DERBY-1712. --- Add a JUnit test decorator that starts the NetworkServer at setUp and stops it at tearDown

[jira] Updated: (DERBY-1558) enable more testcases in ConcurrencyTest

[ http://issues.apache.org/jira/browse/DERBY-1558?page=all ] Andreas Korneliussen updated DERBY-1558: Attachment: DERBY-1558.diff DERBY-1558.stat Attaching patch which enables more testcases in ConcurrencyTest. The patch makes

[jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode

[ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429386 ] Andreas Korneliussen commented on DERBY-418: The finalizer thread is as pr javadoc guaranteed to not hold any user-visible synchronization locks when

[jira] Commented: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=comments#action_12429394 ] Andreas Korneliussen commented on DERBY-1559: - DERBY-1535 caused conflicts with this patch during development. Now, DERBY-1610 will cause conflicts

[jira] Commented: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=comments#action_12429406 ] Andreas Korneliussen commented on DERBY-1559: - I will wait for DERBY-1610 being fixed, to avoid the risk. when receiving a single EXTDTA object

[jira] Commented: (DERBY-1387) Add JMX extensions to Derby

[ http://issues.apache.org/jira/browse/DERBY-1387?page=comments#action_12429432 ] Andreas Korneliussen commented on DERBY-1387: - Hi, thanks for providing this patch. I have tried compiling it, and I do have the following comments

[jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode

[ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429438 ] Andreas Korneliussen commented on DERBY-418: I am not sure what you mean. Could you give an example ? I agree that it is possible to get a deadlock

Re: [jira] Commented: (DERBY-1387) Add JMX extensions to Derby

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sanket Sharma wrote: On 8/21/06, Andreas Korneliussen (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1387?page=comments#action_12429432 ] Andreas Korneliussen commented on DERBY-1387

[jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode

[ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429473 ] Andreas Korneliussen commented on DERBY-418: Assuming the Derby embedded JDBC driver is thread-safe, it should be safe for a result set to call its own

Re: [jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode

Knut Anders Hatlen wrote: Andreas Korneliussen (JIRA) derby-dev@db.apache.org writes: Assuming the Derby embedded JDBC driver is thread-safe, it should be safe for a result set to call its own close() method in its finalizer. If you get a dead-lock in the finalizer, it proves

Re: [jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode

Not sure of the guarantee of the unsynchronized field being set. Are you saying that field will never be seen as set, or that the setting may not be seen for some time? It may be seen, however it may also never be seen. Andreas

[jira] Updated: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen updated DERBY-1559: Urgency: Normal Affects Version/s: 10.2.2.0 10.3.0.0 Derby Info: [Patch Available] I

Re: svn commit: r432569 - /db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: Author: andreask Date: Fri Aug 18 06:05:45 2006 New Revision: 432569 URL: http://svn.apache.org/viewvc?rev=432569view=rev Log: Fixed bug in setUp causing it to only start server when

Re: [junit] frameworks in Junit WAS Re: svn commit: r432569

Daniel John Debrunner wrote: Andreas Korneliussen wrote: Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: Author: andreask Date: Fri Aug 18 06:05:45 2006 New Revision: 432569 URL: http://svn.apache.org/viewvc?rev=432569view=rev Log: Fixed bug in setUp causing it to only start

Re: [junit] frameworks in Junit WAS Re: svn commit: r432569

It won't fail, since the the harness won't start it when _Suite_app.properties contains a property to not start it. My intention with my current set of work for JUnit is to divorce the JUnit tests from the existing harness and have them be able to run standalone. Any time we add dependencies

[jira] Updated: (DERBY-1558) enable more testcases in ConcurrencyTest

[ http://issues.apache.org/jira/browse/DERBY-1558?page=all ] Andreas Korneliussen updated DERBY-1558: Summary: enable more testcases in ConcurrencyTest (was: include ConcurrencyTest into a suite) Description: A number of testcases

[jira] Created: (DERBY-1712) Add a JUnit test decorator that starts the NetworkServer at setUp and stops it at tearDown.

Project: Derby Issue Type: Improvement Components: Test Reporter: Andreas Korneliussen Assigned To: Andreas Korneliussen Fix For: 10.3.0.0 Add a JUnit test decorator that starts the NetworkServer at setUp and stops it at tearDown

[jira] Updated: (DERBY-1712) Add a JUnit test decorator that starts the NetworkServer at setUp and stops it at tearDown.

[ http://issues.apache.org/jira/browse/DERBY-1712?page=all ] Andreas Korneliussen updated DERBY-1712: Attachment: DERBY-1712.diff DERBY-1712.stat The patch (DERBY-1712.diff) has a new class NetworkServerTestSetup. This class

Re: [junit] Move JUnit base/utility classes???

David Van Couvering wrote: Sounds good to me... David Daniel John Debrunner wrote: Currently the JUnit base and utility classes are in this package: org.apache.derbyTesting.functionTests.util (See http://wiki.apache.org/db-derby/DerbyJUnitTesting) I was wondering if they should be moved,

[junit] testname_app.properties replacement mechanism for JUnit tests

I am about to enable more testcases in ConcurrencyTest, which relies on getting a lock timeout to verify a lock conflict. The problem is that default setting for lock timeout is 60 seconds, and the test uses a lot of time waiting for the timeout. I can make the test go 10 times faster by

Re: [junit] Move JUnit base/utility classes???

The functional tests would continue to live in their current location, just that the super-class BaseJDBCTestCase would be in the new package. Thoughts? I support moving the utility classes to a new package. Below are some thoughts on how Junit tests could be structured, in case we would like

[jira] Updated: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen updated DERBY-1559: Attachment: DERBY-1559v2.diff Attached is an updated patch which preserves the changes in DERBY-1535 when receiving multiple EXTDTA objects

[jira] Created: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

://issues.apache.org/jira/browse/DERBY-1696 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0, 10.2.2.0, 10.3.0.0 Reporter: Andreas Korneliussen If an application does the following: Statement s = con.createStatement

Re: DERBY-1057 : patch Derby1057_ref4.diff and a G svn status

Jean T. Anderson wrote: Applying derby1057_ref4.diff gets Reversed (or previously applied) patch detected! Assume -R? so I did this trick: svn up -r 431389 patch -p0 -i derby1057_ref4.diff svn up 'svn status' shows everything looks good except for the ditamap file: G

Re: [VOTE] Approve coding conventions for the Derby project

+1 Adopt the coding convention described. Andreas

Re: AccessControlException on log/logmirror.ctrl after bouncing server...

Myrna van Lunteren wrote: Hi, .. Now here are my ponderables: - why does derbynet.jar need to have this permission, isn't it sufficient for derby.jar to have them (derby.jar has these permissions already). I think it should be sufficient if derby.jar has these permissions, and that you have

[jira] Created: (DERBY-1598) unable to boot exisiting database from network server when running with security manager

Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.2.0.0 Reporter: Andreas Korneliussen Priority: Blocker Myrna van Lunteren reported the following: I ran into the following interesting situation with permissions granted as per

[jira] Closed: (DERBY-1598) unable to boot exisiting database from network server when running with security manager

[ http://issues.apache.org/jira/browse/DERBY-1598?page=all ] Andreas Korneliussen closed DERBY-1598. --- Resolution: Duplicate Duplicate: http://issues.apache.org/jira/browse/DERBY-1241 unable to boot exisiting database from network server when

Re: AccessControlException on log/logmirror.ctrl after bouncing server...

I think this is the same problem as reported in http://issues.apache.org/jira/browse/DERBY-1241 Andreas

[jira] Commented: (DERBY-1241) logmirror.ctrl is getting accessed outside the privileged block when the checkpoint instant is invalid on log factory boot method.

[ http://issues.apache.org/jira/browse/DERBY-1241?page=comments#action_12423822 ] Andreas Korneliussen commented on DERBY-1241: - The following scenario reproduced this problem: 1. Start Network server with security manager enabled 2

[jira] Commented: (DERBY-1545) derbynet/testProtocol.java fails with security manager enabled

[ http://issues.apache.org/jira/browse/DERBY-1545?page=comments#action_12423828 ] Andreas Korneliussen commented on DERBY-1545: - Improved the original patch by also granting permission to ${derbyTesting.serverhost}. This should make

[jira] Updated: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB

[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen updated DERBY-1559: Attachment: DERBY-1559.diff DERBY-1559.stat Attached is a patch which does the following: EXTDTAReaderInputStream

[jira] Commented: (DERBY-1564) wisconsin.sql test failed in DerbyNet framework, VM for network server got OutOfMemoryError

[ http://issues.apache.org/jira/browse/DERBY-1564?page=comments#action_12423858 ] Andreas Korneliussen commented on DERBY-1564: - I think experimenting with different heap-sizes is slightly off-track, since all it may prove

[jira] Commented: (DERBY-1600) JUnit test SURQueryMixTest does not follow the typical pattern for JUnit tests.

[ http://issues.apache.org/jira/browse/DERBY-1600?page=comments#action_12423905 ] Andreas Korneliussen commented on DERBY-1600: - See: http://junit.sourceforge.net/doc/cookstour/cookstour.htm run() is a template method, it will call

[jira] Commented: (DERBY-1587) INTEGER function cannot be abbreviated

[ http://issues.apache.org/jira/browse/DERBY-1587?page=comments#action_12423578 ] Andreas Korneliussen commented on DERBY-1587: - I think the patch looks good and can be committed. INTEGER function cannot be abbreviated

Re: svn commit: r423676 - in /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests: derbynet/testProtocol_app.properties jdbc4/TestQueryObject_app.properties

[EMAIL PROTECTED] wrote: Author: djd Date: Wed Jul 19 17:20:05 2006 New Revision: 423676 URL: http://svn.apache.org/viewvc?rev=423676view=rev Log: Mark test jdbc4/TestQueryObject as failing with the SecurityManager due to DERBY-1540 Remove disablein of SecurityManager for derbynet/testProtocol

[jira] Commented: (DERBY-1545) derbynet/testProtocol.java fails with security manager enabled

[ http://issues.apache.org/jira/browse/DERBY-1545?page=comments#action_12423599 ] Andreas Korneliussen commented on DERBY-1545: - The test code (TestProto is packed into derbyTesting.jar), does new Socket(hostName, 1527

[jira] Assigned: (DERBY-1545) derbynet/testProtocol.java fails with security manager enabled

[ http://issues.apache.org/jira/browse/DERBY-1545?page=all ] Andreas Korneliussen reassigned DERBY-1545: --- Assignee: Andreas Korneliussen derbynet/testProtocol.java fails with security manager enabled

[jira] Updated: (DERBY-1545) derbynet/testProtocol.java fails with security manager enabled

[ http://issues.apache.org/jira/browse/DERBY-1545?page=all ] Andreas Korneliussen updated DERBY-1545: Attachment: DERBY-1545.diff DERBY-1545.stat Attached is a patch (DERBY-1545.diff + stat) which gives socket permission

[jira] Resolved: (DERBY-1587) INTEGER function cannot be abbreviated

[ http://issues.apache.org/jira/browse/DERBY-1587?page=all ] Andreas Korneliussen resolved DERBY-1587. - Fix Version/s: 10.2.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) Thanks for contributing. Committed revision

[jira] Resolved: (DERBY-1545) derbynet/testProtocol.java fails with security manager enabled

[ http://issues.apache.org/jira/browse/DERBY-1545?page=all ] Andreas Korneliussen resolved DERBY-1545. - Fix Version/s: 10.2.0.0 Resolution: Fixed Committed revision 425732. derbynet/testProtocol.java fails with security manager enabled

[jira] Closed: (DERBY-1545) derbynet/testProtocol.java fails with security manager enabled

[ http://issues.apache.org/jira/browse/DERBY-1545?page=all ] Andreas Korneliussen closed DERBY-1545. --- derbynet/testProtocol.java fails with security manager enabled -- Key

[jira] Created: (DERBY-1595) Network server fails with DRDAProtocolException if a BLOB with size 2147483647 is streamed from client

/browse/DERBY-1595 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.2.0.0 Reporter: Andreas Korneliussen Priority: Minor When executing a program which inserts a BLOB of size 2GB-1, the Network server fails

Re: [jira] Resolved: (DERBY-1545) derbynet/testProtocol.java fails with security manager enabled

Myrna van Lunteren wrote: Hi, I have a question on the commit. You added permissions for localhost and 127.0.0.1, i.e. also localhost... I think this means this problem might then still pop up in remote server testing, no? I don't understand the nature of the problem...but I think this means

[jira] Resolved: (DERBY-1296) Setting property derby.system.bootAll causes an Exception

[ http://issues.apache.org/jira/browse/DERBY-1296?page=all ] Andreas Korneliussen resolved DERBY-1296. - Resolution: Fixed Derby Info: (was: [Patch Available]) Thanks for resolving the conflict. Committed revision 425388. Setting

[jira] Commented: (DERBY-1535) Trial 2 for DERBY-550, improve use of Engine from NetworkServer and reduce memory usage

[ http://issues.apache.org/jira/browse/DERBY-1535?page=comments#action_12423375 ] Andreas Korneliussen commented on DERBY-1535: - I think there could be a problem here: DRDAConnThread

  1   2   3   4   5   6   >